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

[Robert Schwebel]

Meeting der OSADL Joint Technical Working Group Automation     rsc, 20070109-2
------------------------------------------------------------------------------

CBE Carsten Emde, OSADL eG
WGR Wolfgang Grandegger, Denx
RSC Robert Schwebel, Pengutronix e.K.
MKL Marc Kleine-Budde, Pengutronix e.K.
ABA Alexander Bauer, Phytec Meßtechnik GmbH
DHE Dieter Hess, 3S Software Solutions GmbH
MKR Michael Krämer, Holzbearbeitungssysteme AG
UDO Ulrich Doll, Homag Holzbearbeitungssysteme AG
HGR Herbert Graf, Homag Holzbearbeitungssysteme AG
MAI Klaus Maier, ISG Industrielle Steuerungstechnik GmbH
TKH Thomas Köhler, ISG Industrielle Steuerungstechnik GmbH
MBU Matthias Bühler, TRUMPF Laser GmbH + Co. KG
GKO Gerd König, Kontron Modular Computers GmbH
MDU Matthias Duckeck, Kontron Modular Computers GmbH
RBO Reinhard Borst, Eltec Elektronik AG
HEG Heinz Egger, Linutronix
TGL Thomas Gleixner, Linutronix

Kurze Einführungsrunde, Vorstellung. CBE stellt die Agenda vor.

CBE: die Entwicklung eines allgemeinen Frameworks ist vermutlich sehr
aufwendig, deshalb wird man übergangsweise auch andere Lösungen wie RTDM
zulassen müssen.

WGR: Das I/O Framework wiederspricht ja nicht dem, daß man es über RTDM
implementiert. Man muß erst mal die Schnittstellen oben im Userspace
definieren.

UDO: die Fixierung auf Ethercat ist relativ unglücklich. Besser eine
allgemeine Lösung schaffen.

TGL: das gemeinsame Interface kommt erst auf dem Top Layer zustande -
Vereinheitlichung für die Applikation. Auf den drunterliegenden
Schichten stellt sich die Frage, wie man solche Protokolle überhaupt
integriert. Unten drunter braucht man einen deterministischen
Transportmechanismus.

DHE: man sollte erst mal definieren, was drin ist und was nicht.
Begriffesammlung:

	* Prozeßdatentransport
	* asynchrone Nachrichten vom/zum Teilnehmer
	* Diagnose, welche Teilnehmer sind da und nicht

TGL: das ist das Ziel. Der oberste Layer, auf dem Applikationen
aufsetzen, ist das Fieldbus Device Interface (FDDI). UDO zeigt den
aktuellen Stand des Diagramms.

TGL:

	* Field Layer: Geräte. Zu dem gehört immer ein Kerneltreiber.
	  Das kann auch das UIO Framework sein. DMA ist noch nicht
	  implementiert, aber vorgesehen.

	* Für Netzwerk wird der Userspace einfach ein Socket sehen.
	  TGL hat mit den Netzwerk-Leuten gesprochen, die krempeln
	  gerade den Stack komplett um. Performance Probleme, 10 GBit.
	  Es kommt ein großer Druck aus dem Enterprise Bereich, die
	  brauchen deterministischens Scheduling und Packet Transport.
	  Bei Banktransaktionsservern müssen lt. Börsenaufsicht in
	  Zukunft den Eingang von dem Transaktionspaket auf dem Netzwerk
	  loggen. Da sitzen 1400 Ingenieure dran.

RSC: Zielvorstellung ist deterministischer Netzwerk-Stack. Die Frage
ist, welche Richtung gibt man den Kunden vor, damit sie nicht jetzt auf
dem UIO Framework aufsetzen und das hinterher nicht wieder anschauen.
Die Vorgabe der NetChannel Leute ist, bis Ende des Jahres einen
entsprechenden Patch zu haben.

RTS an TGL: habt Ihr mal Messungen gemacht? TGL: ja, auf Raw Socket
gemacht. Trumpf hat mit TCP und Corba gemessen: Typische Zeit bei
TCP/IP: 400 Microsekunden Round Trip. TGL: hat schon einen Ethercat
Stack auf Raw Socket portiert, das funktioniert.

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.

Konkret: Ethercat Stack wäre ein High Level Driver ("Fieldbus Device
Driver"). Programmiert gegen die Low Level Driver Schnittstelle, die ihm
ein gewrapptes Socket zur Verfügung stellt.

LLDI: öffne, lese Paket, schreibe Paket, Event.

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.

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.

DHE: es gibt zwei Konfigs: die Strukturbeschreibung (die ist relativ
generisch) und die Feldbus-Beschreibung (die ist oft sehr spezifisch).
Man könnte von den Lieferanten fordern: wenn er OSADL konform sein soll,
_muß_ er einen Treiber liefern, der das generische Format parsen und was
für die Karte liefern können. Von der oberen Schicht haben z.B. Homag,
ISG und 3S genaue Vorstellungen.

DHE: Es gibt auf jeder Interfaceebene Profile, die gleichartike Geräte
zusammenfassen. Es muß sichergestellt werden, daß es für jede
Geräteklasse nur ein OSADL Profil gibt. Wie geht man damit um, daß es
z.B. CAN Chips gibt, die eigenständig PDOs liefern? Es muß klar sein,
daß ein CAN/Open immer auf ein vollständiges nachrichtenbasiertes
Interface nach unten zugreifen kann.

Vorgehensweise: UDO & Co. stellt das Homag Konzept für den Mapping Layer
vor:

	* Auf LDI-Layer: z.B. CNC Objekt und PLC Objekt
	* z.B. ein CNC Objekt mappt auf mehrere Logical Objects
	* diese wiederum auf verschiedene Communication Objects
	* diese wiederm auf Fieldbus Device Functions

DHE: viele Schichten haben mit Linux eigentlich überhaupt nichts mehr zu
tun. Alles unterhalb vom LLDI wäre Linux spezifisch. Viele Komponenten
sind einfach in C implementiert und müssen dann cross platform sein. Da
sind sich alle einig: Wo POSIX ist, sollte man es nehmen.

Konsens:

	* Alles unterhalb des FDDI Layers ist C und benutzt, wenn es
	  Bettriebssystem-Funktionen braucht, POSIX.

Sammlung der Profile für das System Interface:

	* tty
	* socket (AF_INET, AF_CAN)
	* uio (mmap+Interrupts+DMA)
	* File (read/write/ioctl/mmap)
	* x86 Ports (ioperm, imb, outb)
	* usb (Usersace Treiber vs. Subsysteme)

Sammlung der Profile für das LLDI Interface:

	* Management-Schnittstelle:

		- Enumeration: liefert Typ und Instanz.
		  lldi_open, lldi_close, lldi_status,
		  lldi_init,
		  lldi_param_detect, lldi_param_get, lldi_param_set
		- Introspektierbarkeit über capabilities.
		- Exclusives, nicht exclusives Open
		- Parameter-Sätze müssen für Profile definiert werden

	* Zwei Profile:

		- Message

		  lldi_recv, lldi_send

		  Wenn das Gerät Paketierung unterstützt, gibt es nur
		  ganze Pakete zurück. Geht aber nicht überall, weil
		  dies der Transport Layer ist - d.h. hier möchte man
		  nichts Protokoll-spezifisches haben.

		- Prozeßabbild

		  Ist ein Stück Speicher, was da drin ist, weiß der
		  Layer drunter nicht.

		  lldi_...

	* lldi_message
	* lldi_file_read,lldi_file_write

Sammlung für FDDI Schnittstelle:

	* Management-Schnittstelle:

		- Enumeration: liefert Tree aus Interfaces und I/O Knoten
		- "Ich bin ein Feldbusgerät und ich habe einen Knoten"
		- Oder bei CAN/Open: "Feldbus Gerät mit 4 Knoten"
		- Parametrierungsschnittstelle, kann z.B. XML File
		  fressen, das das I/O System hinter dem CAN/Open
		  definiert. fddi_fahr_dein_canopen_stack_an
		- Es gibt Geräte die gerade mal nicht da sind, aber
		  trotzdem parametriert sind (Offline/Fehler)
		- Es gibt Geräte, die können ihre Eigenschaften selber
		  veröffentichen und andere, die eine Parametrierung
		  brauchen.

	* Knoten-Schnittstelle:

		- Knoten initialisieren
		- Buszyklus auslösen
		- Kommando schicken: fddi_send_request
		- Callback für Kommando lesen: fddi_recv_request;
		  blocking, nonblocking

	* Prozeßabbild:

		- Das PA ist hier immer noch per Strang/Knoten

Ganz, ganz oben:

	* Es gibt noch den Unterschied zwischen "Transporteinheiten" und
	  "Knoten": z.B. bei EtherCAT: da können auf einer Zeitscheibe
	  andere I/Os reinkommen als auf der anderen, aber weil es die
	  gleiche Klemme ist, kann die z.B. nur Strom haben oder nicht.

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

* Low Level Gruppe: Denx, PTX, Linutronix, ...?

* Keine Spezifikation ohne Implementierung, das muß man zusammen machen.

* Szenario festlegen für Proof of Concept:

	* Profinet
	* EtherCAT
	* Socket CAN
	* EC1
	* PC und PowerPC (mindestens)

* Ziel:

	* Schnelle Iteration und Synchronisation per Mailingliste
	* Meeting auf der Embedded World zwecks Synchronisation

-- 
 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OSADL-IO-Framework-FFM.pdf
Type: application/pdf
Size: 34107 bytes
Desc: not available
Url : https://lists.osadl.org/pipermail/ag-automation/attachments/20070117/e7e2a57f/attachment-0001.pdf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IOFramework_v0.1.odp
Type: application/vnd.oasis.opendocument.presentation
Size: 220669 bytes
Desc: not available
Url : https://lists.osadl.org/pipermail/ag-automation/attachments/20070117/e7e2a57f/attachment-0001.odp