[ag-automation] [PROTIKOLL] AG Automation Meeting vom 09.01.2007

[Robert Schwebel]

Dear Colleagues,

On Wed, Jan 17, 2007 at 12:18:17PM +0100, Robert Schwebel wrote:
> * Ziel:
> 
> 	* Schnelle Iteration und Synchronisation per Mailingliste
> 	* Meeting auf der Embedded World zwecks Synchronisation

Well, to achieve this aim, we start with the discussion now :)

> Damit wäre die Vorgabe für Leute, die heute schon starten wollen: Low
> Layer wegwerfen und sich auf Raw Socket setzen. Code in Userspace
> bringen, Fieldbus Device Driver.

That's how we will start for our EPL activities.

> Konfigurations-Problematik: Die Low Level Treiber brauchen
> Konfigurationsdaten, die Fieldbus Treiber brauchen
> konfigurationsdaten.  Sollte zusammen passen. Beispiel: ein Ethercat
> braucht die Konfiguration, die ihm sagt, wo da draußen die Daten im
> Frame liegen.  Wir machen eine protokollunabhängige Konfiguration, die
> dann wieder an die spezifischen Konfigurationen ankabelt. Ethercat
> braucht irgendwelche FMMUs mit irgendwelchen Parametern. Wie geht man
> mit unterschiedlichen Konfigurationsdatenformaten z.B. für Ethercat
> um? Gibt es einen unabhängigen Konfigurator? TGL: interessant wäre,
> wenn man unabhängige Konfiguratoren hätte; wenn nicht, würde man auf
> der jeweiligen Schicht den proprietären Konfigurator benutzen. RSC:
> gibt es eine Vorstellung, wie das von ganz, ganz oben aussieht? UDO:
> da hat Homag eine.

Is it possible to get an impression of the Homag config model as a
starting point for the discussion of this topic? 

We have once written a relatively simple I/O model for one of our open
source projects (a backend library for tglx' JVisu), which basically
looks like this - I'll use an xml representation here, but this easily
mapps to an object diagram and probably will be implemented as one in
the c/c++/whatever code:

A "subSystem" is a logical/physical hardware unit:

	<subSystem>
		...	
	</subSystem>

Maybe there is a better name, but subSystem is basically what we called
a "node" in the discussion.

It can have "ports" to connect to the outside world, for example an
ethernet port:

	<port id="eth0">
	  <device prefix="eth" index="0" direction="inout"/>
	  <portEthernet>
	    <ip>192.168.23.1</ip>
	    <broadcast/>
	    <mac/>
	    ...
	  </portEthernet>
	</port>

Or a CAN port:

	<port id="can0">
	  <device prefix="can" index="0" direction="inout"/>
	  <portCan>
	    <baudrate>250000</baudrate>
	  </portCan>
	</port>

Or a serial port:

	<port id="ttyS1">
	  <device prefix="/dev/ttyS" index="0" direction="inout"/>
	  <name>Debug port</name>
	  <portSerial>
	    <baudrate>115200</baudrate>
	    <parity>None</parity>
	    <bits>8</bits>
	    <stopBits>1</stopBits>
	    <softFlowControl>0</softFlowControl>
	  </portSerial>
	</port>

You get the picture. As you can see, "ports" are connecting elements
between subsystems; they are "base classes" which can have "derived
classes" with more specialized elements.

All elements can have further <property id="key" val="value"/> tags, so
that you can add arbitrary information.

Due to the "device" tags, there is direction information available for
the nodes, so you can build verificable "schematics" out of such a
thing. In fact, one could probably use one of the simple PCB programs
out there as a net plan builder :)

For nodes which offer process image data, we have a simple process image
abstraction; our abstraction directly refers to a global process image,
this will probably be different in the OSADL model:

	<processimage>

	  <pv id="scale" val = "1">
	    <type>uint32_t</type>
	    <offset>0x0</offset>
	    <name>Scale</name>
	  </pv>

	  <pv id="freq" val = "1">
	    <type>int32_t</type>
	    <offset>0x4</offset>
	    <name>Freq</name>
	  </pv>

	  <pv id="amp" val ="1000">
	    <type>uint32_t</type>
	    <offset>0x8</offset>
	    <name>Amp</name>
	  </pv>

	  <pv id="array">
	    <type>uint32_t</type>
	    <offset>0xc</offset>
	    <repeat>32</repeat>
	    <name>Array</name>
	  </pv>

	</processimage>

So you can directly map this node sniplet to a global PI and specify
offsets here, plus information which is necessary to define what a pv
means; pvs can have name, scale, unit, max, min and bit width. 

We have defined RNG schemata for the format, so if somebody is
interested, I could make it available on our OSS website. In the end,
the data model was developed with graphical modelling tools in mind, but
we never had the time to implement that part yet.

Taken the structure we've discussed during the meeting, it would be
possible to call into the config layer of the OSADL I/O stack, enumerate
the device tree and ask the objects to demarshall into that kind of xml
sniplets. Objects which are introspectable could directly offer their
description ("hey, clamp, tell me what you are and what you have"), and
dumb devices would somehow bring the sniplets with them in a manual way.

In short: I'd like to learn if either this model could be a starting
point for an OSADL OpenIO configuration model, or if the Homag model has
a better abstraction, or we could merge and make a third one which
offers what we need.

It would be a good exercise to take a description of a complex
automation device and look how it fits into the models.

> Beispiel von oben: Man hat ein XML, das einem das System von oben
> beschreibt. Welche Feldbusse sind da drin, Stränge, Knotenobjekte. Die
> Knotenobjekte werden wieder separat beschrieben. Nehmen wir den Knoten
> 4711; wenn der so intelligent ist, daß er die Konfig selber auswerten
> kann und daraus seine Konfig lesen kann, ist das gut; wenn nicht, nimmt
> er halt einen vom proprietären Konfigurator gebauten BLOB.

The data model is extensible, so this could easily be done with what
I've outlined above.

> Vorgehensweise
> --------------
> 
> * Homage, ISG, 3S möchte eine Arbeitsgruppe für "oben" bilden
> 
> * Es sollte je ein Member aus der einen in der anderen Arbeitsgruppe
>   sitzen

We will be interested in playing the spy role in the "upper layer
working group".

> * Szenario festlegen für Proof of Concept:
> 
> 	* Profinet
> 	* EtherCAT
> 	* Socket CAN
> 	* EC1
> 	* PC und PowerPC (mindestens)
 
So if we sould like to work on a demo system for the SPS/IPC/Drives, I'd
suggest that we define a hardware demonstrator right now. We all know
that tradeshows are like christmas, once they are there, nobody has
realized how this could happen so quickly, again :-)

So please let's define a demonstrator layout quickly, let's see that we
get the necessary hardware components and let's put it to some location
where it has permanent internet connectivity (we could offer our remote
lab services easily). Some ideas for components I'd like to see:

- PC: let's take some more or less normal PC, maybe Eltec could sponsor
  one. It needs standard PCI slots, the more, the better, and a CPU
  and chipset which is known to have no problems with realtime.

- Interface cards for the PC: CAN (we have drivers for IXXAT SJA1000 as
  a starting point); EtherCAT (does it need more than a dedicated
  network card?); separate network port for non-realtime

- PowerPC/ARM: Phytec could probably sponsor an phyCORE-MPC5200 and
  phyCORE-PXA270, both with CAN interfaces (MSCAN, SJA1000). Realtime
  and CAN drivers are ready to be used.

- Network infrastructure: at least an 8 port hub for realtime
  networking. One switch for normal networking. CAN cabeling.

- I/O on CAN: CAN/Open clamp (we have a Wago one), motion device (any
  idea, anyone?).

- I/O on EtherCAT: TBD, probably some Beckoff I/Os plus motion?

- I/O on EPL: TBD, probably some Wago I/Os?

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