[ag-automation] FDDI Overview

[Robert Schwebel]

It looks like there is some progress on the fieldbus front, which is
definitely a good thing.

Some remarks about the 3S proposal:

On Wed, May 02, 2007 at 05:50:53PM +0200, Dieter Hess wrote:
> Low Level Device Interface (LLDI)
> 
> This interface supplies uniform access to IO-interface hardware with
> the same profile, in order allow upper layers to have only one
> implementation for a specific IO-protocol. For example the LLDI should
> provide a uniform access to all CAN interfaces, to allow hardware
> independent implementations of CANopen or DeviceNet Stacks.

We should clarify here that this is true for "real" CAN cards. Hilscher
CIF cards for example may speak CANopen but do not represent this to the
stack.

> Other typical profiles are Ethernet interfaces, Sercos interfaces,
> serial interface, Hischer fieldbus card, etc. The different profiles
> do not have necessarily the same interface function definitions, but
> should follow the same patterns (for example the socket pattern) as
> far as possible.

Ack. We may also start making chapters for the different "device
classes". I would avoid the term "profile" here, as it is too biased in
legacy automation terminology.

> Fieldbus Device Driver Interface (FDDI)
> 
> This interface allows applications to access IO-subsystems in a
> uniform way. It manages IO interfaces, IO devices, process data and IO
> channels. 
>
> Logical Device Interface (LDI)
>
> This interface supplies
> application entities in a uniform way, independent of the underlying
> IO-interface.  A typical entity supplied by the LDI is a servo drive.
> 
> 1.2 Entities of the FDDI
> 
> The FDDI interface handles four different entities:

[...]

> IO-Interfaces
> 
> IO-interfaces represent the software (that means the driver or
> protocol stack), which implements a specific I/O-protocol. The
> instance of an IO-interface is bound to a specific IO-Interface
> hardware supplied by the LLDI in the initialisation phase of the
> system.

Hmm, I don't understand what these IO-Interfaces exactly do.

> Operations supported for IO-interfaces and instances of IO-Interfaces
> are:
> 
> - Enumeration (divers and driver instances)

You mean something like "what CAN interfaces do we have on this
hardware -> can0, can1"? How does that fit the model that IO-Interfaces
can exist even if the underlying hardware interface does not? Let's
assume that we use an USB CAN adapter, for example. How would the
enumeration work in that case?

> - Instantiation

Dito.

> - Information (name, version, required LLDI profile)

This should be done by using key/value properties, with some of them
standardized in profiles.

> - Configuration (setup of parameters and expected IO-devices)

This is a wide field and we need a good model for it.

> - Scan (list of the actual connected devices)
> - Diagnosis/Operation state

You mean that the "IO-Interface" object has an internal state machine
for that?

> - Commands (start, stop, reset, identify)

Ok, object methods.

> - Enumeration of configured devices (IO-devices)
> - Enumeration of process data transport units (IO-transport units)
> - Enumeration of IO-channels

[...]

> IO-Devices
> 
> IO-devices are the configured devices of an IO-interface. If there is
> a physical device matching an IO-device it represents the physical
> device. There can be devices, which do not match with physical devices
> at a given time and there can be physical devices ,which are not
> associated with any IO-device. The IO-interface must do the matching
> between configured and physical devices at configuration time and can
> support the matching at runtime if required. 

I still don't really understand how you mean this. Is an IO-Device the
equivalent of the kernel drivermodel "device" instance, i.e. a software
object representing some hardware? That would make sense. But then the
"IO-Interfaces" are badly named.

> Operations supported for IO-devices are:
> 
> - Information (logical ID, physical ID, type ID, name)

See above, let's use some generic introspection mechanism here.

> - Diagnosis/operation state
> - Asynchronous read/write services
> - Commands (start, stop, reset, identify, save param)
> - Enumeration of IO-channels

Ack.

> IO-Transport Units
> 
> IO-transport units are chunks of process data, transferred by the
> underlying low level device at the same time (from the application
> point of view).

With "time" you mean that some, let's call it event source, at some time
decides to say something like "here I have a bunch of process
variables"?

> IO-transport units are not necessarily bound to IO-devices.

Why not? Who else can emit them?

> An IO-transport unit can represent only a part of a device or can
> cover more than one device. Examples for I/O-transport units are
> CANopen PDOs, EtherCAT FMMUs, the complete input and the complete
> output process image of a intelligent field bus interface card.

We should model that as "process variables" plus "containers of process
variables".

> Any I/O transport operation is done with IO-transport units. The
> number, size and layout of all IO-transport units is determined by the
> configuration of the IO-interface. 

This looks like a layer violation to me. If the IO-Devices are "below"
the IO-Interfaces, how could the IO-Interface provide these information?

> The process memory contained in I/O-transport units are implemented in
> a managing layer, which is used by the LLDI, FDDI and the application
> layers above in common. This management layer handles access control
> and buffering.

Note that we have already implemented something like that in libpv. It
provides a backing-store (shared memory or persistant storage) based
process variable space with locking.

> Operations supported for transport units are:
> 
> - Information (ID, time stamp, direction: in/out, sync attribute)
> - Access (get address to read, get address to write, release)

Your transport units look more like events+data to me, so how can that
have access attributes? That would more be a property of an event
channel / IO-Channel than of the events, wouldn't it?

> - Registration to receive event
> - Explicit send
> - Enumeration of IO-channels

I'd welcome some UML class diagrams to get a better understanding of
what you mean.

> IO-Channels
> 
> An IO-channel represents a single IO-signal. 

Let's not confuse wording. A channel is an infrastructure which can
transport events, and an event is a transient thing which can be
emitted, received and can contain data. A signal is more equal to an
event than to a channel.

> The data/value of a channel is stored on a certain offset in the
> IO-transport unit, to which the channel belongs.

So do I understand it correctly that you have something in mind like
a channel-attached process image?

> The following operation is available for IO-channels:
> 
> - Information (ID, Type/Size, IO-transport unit, IO-device, offset in
>   memory of transport unit)

I still don't understand why we need this referencing stuff.

> All information delivered can be assumed to be constant in a given
> configuration.

What is "a given configuration"?
 
> 1.3 Typical usage scenario of the FDDI
> 
> To clarify the usage of the FDDI the typical sequence of operations is
> explained:
> 
> At system initialisation:
> 
> Available IO-Interfaces are enumerated and instantiated with the
> available IO-interfaces supplied by the LLDI. 

Notice that you already confuse the naming here. Let's avoid this
"interface" term because there are already too many interfaces in such a
system. Either invent something different or prefix it by some
meaningful thing, like "FDDI-Interface" or "Device-Interface" etc.

> For example a CANopen IO-interface is bound to the first CAN interface
> of the system and a DeviceNet IO-Interface is bound to the second CAN
> interface of the system.

Wait, above your IO-Interface was more of a managing thing which sits
ontop of the devices and manages them. So I don't understand how
something like this can be "bound" to a hardware-interface. Wouldn't it
be bound to an IO-Device?

> At application initialisation:
> 
> The configuration of an IO-interface is done. 

Wouldn't the IO-Interface do the configuration of the IO-Devices? Or did
I get this wrong?

> The source of the configuration can be either a file or a explicit
> configuration.

What is an "explicit configuration"? I would suggest that the source of
configuration is either introspection of some device object, or a config
file. In any case it should be abstracted by a configuration object.

> After the configuration all IO-devices, IO-transport units and
> IO-channels are defined for the specific interface. Before
> configuration just a few operation with the device are possible like
> scan or identify.

We should define states for some of the objects.

> At application runtime:
> 
> The enumeration operations are used to get the I/O-channels. They are
> accessed through the IOtransport unit, which contained them. 

Could you give us a pseudo code example for that?

> To access them a read or write address to the memory buffer of the
> transport unit is retrieved.

That's what we do in libpv. You instanciate a process variable engine
(error handling and details left out):

	pv_init(&pv_engine, &attr);

Then you can register variables:

	button_up = pv_register_int8(&pv_engine, "button1"));

So button_up is a pointer now, which can be manipulated:

	pv_lock(&pv_engine);
	printf("the button state is %i\n", *button_up);
	pv_unlock(&pv_engine);

> By using the offset and size of the channel, the value is read or
> written. 

Please don't use things like offsets and sizes here. Use an object
oriented model. Offsets and sizes are implementation details.

> After the access the pointer must be released. During the access it is
> guaranteed that no other layer of the IO-framework and no other client
> of the FDDI changes the process data.

One drawback of libpv is that it currently only supports
per-process-image locks; we should probably also have "per
process-variable-set" locks or "per process-variable" locks.

> If the IO-interface and the application are not strictly coupled the
> channels are simply accessed. If the IO-interface triggers the
> application, the registration to the receive event of I/O-transport
> units can be used to implement an event driven application. If the
> application triggers the I/O-interface the "explicit send" operation
> of the IO-transport unit can be used. In which way the transfer of the
> I/O-transport units of the IO-interface are triggered is determined by
> the configuration of the I/O-interface. The state of the IO-devices
> attached to an IO-interface can be processed by enumeration them and
> use the diagnosis function of the IO-device.

I'd like to see this a little bit more outlined, probably also with
pseudo code.

In general, this looks like a good start to me. Nevertheless, I see
several points which have to be clarified and discussed. So I suggest
that we organize another workshop meeting. Carsten, could you organize
this?

Regards,
Robert Schwebel 
-- 
 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