[ag-automation] OSADL FDDI remarks

[Robert Schwebel]

Hi Peter,

On Wed, Apr 30, 2008 at 05:22:53PM +0200, Peter Soetens wrote:
> We're looking for a small C library which allows to communicate
> different kinds of 'data' over any kind of bus (CAN, Ethernet,...)
> from device A to device B and the other way round. We're happy with
> 'hardcoding' the link from A to B in the lowest layers, so no
> XML-configuration required yet. Instead of reinventing the wheel,
> we're taking a look at the FDDI library.

Good idea!

> It looks like FDDI development stopped at the point where it got
> interesting :-).

Not at all :) It's just not visible to the outside at the moment, due to
the fact that we are heavily working towards a new prototype which
fulfills even more usecases.

> It can 'discover' and 'command' devices, but not exchange data
> (process variables). There are two use cases in the tests directory
> which define the API for the to-be-written LDI.

It turned out that the "bottom up" design doesn't necessarily lead so
something useful, so we are currently coding another prototype which
starts at the top level (application interface) and works down to the
lower (fieldbus) layers. My current impression is that this will work
out much better.

>  * Is there any implementation/beta code of the LDI interface yet ?
>  * Could you comment on the 'readyness' of the LDI API in the use cases,
>    meaning, is it ripe/complete/final ?

Well, we have a working prototype that is able to parse proprietary CAN
protocols (you define an xml file that specifies that identifier
$something has the engine speed encoded in little endian in bytes 2 and
3) and it magically maps that to process variables, whith locking,
persistence, multi instance support, namespaces for actors (e.g. plc,
cnc, LabView VI, Matlab or whatever).

Regarding the "readiness", we are currently writing down a project plan
for how the remaining bits and pieces could be developed. As the
interest throughout our customers as well as in OSADL seems to be
immense, I'm currently positive that we get a working business plan for
how to proceed with the missing things.

>  * Also, is there by any chance uncommited code/documentation/examples ? We're
>    basically reverse engineering the code to understand what's happening (which
>    is ok given the small amount, but still...)

No need to do that.

>  * What's the relation with FAPIA, which is written in C++ ?

FAPIA comes from the Homag people, who heavily work with C++ and CORBA.
However, although it may contain some good ideas, I think that it is
only a small part of what the market demands.

We currently have the situation that we have a bunch of end user
markets:

- commercial: control leds on mobile devices
- automation: classical plc patterns (read/calculate/write/cycle)
- control: event triggered actors (data-in/process/data-ready), with
  closed loop requirements
- measurement: spool data through a system, oneway only, but high
  performance

plus a big variety of coding philosophies:

- IEC61131 in a soft plc
- hand written C code
- model based design (say Rhapsody, LabView, Matlab/Simulink)

in combination with a bunch of languages:

- C
- C++
- IEC61131
- Python
- Shell
- Java
- C#

And, of course, a variety of hardware pieces:

- 50 MHz ARM7, mmu-less (low end)
- 200 MHz ARM9, with mmu (mainstream embedded)
- 400-600 MHz ARM11, PowerPC (mainstream embedded)
- 500-1000 MHz Mobile PC (high end embedded)
- 1-3 GHz Multicore PC (highest end embedded)
- DSP platforms (like Blackfin, mmu-less)
- FPGAs (softcore, NIOS, Microblaze)

All this is reality in our projects and has to be supported by a generic
I/O framework. There is no sense in excluding a big part of the market,
just because it uses the wrong programming language.

So how can we proceed? First of all, please wait a few days until I'm
finished writing the technological proposal and finishing the next step
of the prototype. I'd like to see the commercial perspective sorted out
first; to finalize things in a professional way, it needs commercial
commitments with the people who are interested. When we continue on a
spare time base or with the speed of our customer projects, but that's
probably not the fastest way go come to an end for the *generic*
solution.

> I thank Robert in advance for his answers :-)

My pleasure :)

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9