[ag-automation] Protocol of the 2006-04-24 meeting

Tue Apr 25 07:46:54 CEST 2006

Dear Sirs, 

Here's the protocol of yesterday's JTWG Automation meeting.
Unfortunately in German right now, if somebody feels inspired to
translate it into English please speak up. 

OSADL JTWG Automation Meeting                     rsc, 2006-04-24, 10:30-17:00
------------------------------------------------------------------------------

Teilnehmer: 

ABA Alexander Bauer, Phytec
JAL Jan Altenberg, Homag
MBU Matthias Bühler, Trumpf
ABR Andreas Breunig, Eltec
WDE Wolfgang Denk, Denx
LFU Luotao Fu, Pengutronix
TGL Thomas Gleixner, Linutronix
WGR Wolfgang Grandegger, Denx
BHU Bodo Huber, Phytec
HJE Harald Jennerich, Eltec
MKL Marc Kleine-Budde, Pengutronix
ALE Armin Lechner
KMA Klaus Maier, ISG
DSC Dirk Schiller, ISG
RSC Robert Schwebel, Pengutronix
BSP Benedikt Spranger, Linutronix
MWI Markus Wild, Homag

Vorstellungsrunde
=================

Da in der Runde viele neue Gesichter sind, stellen die Beteiligten sich
und ihre Unternehmen vor. 

Pengutronix
-----------

Schwebel, Fu, Kleine-Budde: Linux-Dienstleistungen, Professionalisierung
von Basistechnologie (Linux von der Technologie zum Produkt); I/O
Framework, Feldbusse.

OSADL-Projekte: I/O Framework, RT-Preempt im Hinblick auf Board Support, CD.

ISG
---

Maier: Sind Anwender, Kunde möchte die CNC portieren auf Linux, I/O
Framework, Treiber, Interoperabilität (z.B. mit 3S CoDeSys).
Formulierung der Schwerpunkte von der Anwenderseite her. Lechner: Sercos
III, Unterstützung des Protokolls, Konformitätstests, Linux als
Entwicklungstool, Einstieg mit Sercos erleichtern.

OSADL-Projekte: I/O Framework

Homag
-----

Wild: Homag hat modulares Steuerungskonzept, "Konfektionierung" der
Steuerungen. Führt vor allem zu Vorteilen in der Organisation, schnelle
time-to-market. OS9 Ära ist vorbei, die nächste Generation ist entweder
Linux oder Siemens. Heute sind bei OSS keine "Zyklen" erkennbar. Ziel:
viele Leute hinter die Technologie bringen! Nachvollziehbare
Qualitätsmerkmale, Konformitätstests, I/O Standards. Ziel heute: wer
kann wo mitmachen, wer kann was beisteuern.

OSADL-Projekte: Live-CD, OPC, I/O Framework (nur nutzen).

Trumpf
------

Haben eine Steuerung mit Linux entwickelt.

OSADL-Projekte: Testing (im Hinblick auf Projekt), RT-Preempt, IIO

Linutronix
----------

BSP: Industrial I/O Framework; TGL: entwickelt Preempt-RT, möchte
objektive Bewertungskriterien, darüber hinaus standardisierte Frameworks
für Industrial I/O, Userspace Device Driver - bisher gibt es noch keine
sinnvolle Framework-Idee, aber das Preempt-RT Modell paßt hier.
Umlenkung von Dingen, die "einfach nur da sind" in generische Lösungen.
Es gibt für I/O keinen Standard, auf den die Hersteller abfahren.

OSADL-Projekte: I/O Framework, Testing. 

Denx
----

WDE: decken alle Schichten zwischen Applikation und Hardware an. Im
Rahmen der Projekte spielen Steuerungsanwendungen & Echtzeit immer mal
wieder eine Rolle. Denx vollzieht momentan den Schwenk von RTAI zu
Xenomai. Strategisches Ziel: wenn es um Standardisierungen geht, muß der
Fokus auf Schnittstellen und Interoperabilität liegen, nicht auf einer
konkreten Implementierung. Findet die verschiedenen Möglichkeiten nicht
schlecht -> Mutation und Selektrion. 

OSADL-Projekte: I/O Framework

Eltec
-----

Kommen von OS9, unter Linux geht es los, u.a. Janz I/O. Konstanthaltung
von Software auch über längere Zeit hin. I/O-Spezifikation ist
interessant, alles was mit Hardware-Zugriff zu tun hat. 

OSADL-Projekte: Testing

Phytec
------

Microprozessor-Boards, werden auch in Steuerungsprojekten eingesetzt.
Aufgrund von nicht vorhandenen Schnittstellen, Interoperabilität wird
viel Zeit in die Hardware-Anbindung investiert. 

OSADL-Projekte: I/O Framework, Socket-CAN

Diskussion
==========

MWI: Evolution muß Auswahl bedeuten! Eines der größten Probleme ist das
Retrofitting bei der Anwendung. Wie bekommt man das hin, daß man genug
kritische Masse hinter das Projekt bringt? Vertrauen schaffen im Markt,
wie bekommt man Anwender dazu, auf der Plattform aufzubauen?
Anfangskristallisationspunkte, Dokumentation - was muß man tun, um ein
Echtzeitprogramm zu machen? Viele Entwickler sind sehr schwer zu
motivieren, mitzumachen! Entwicklungsumgebung ist wichtig. Wir brauchen
POSIX Interface. Einfache Vorgehensweisen. 

WGR: Kann man Schnittstelle so definieren, daß sie sowohl für RT-Preempt
und Xenomai funktioniert? BSP: Man kann vermutlich vieles mit einer
entsprechenden Bibliothek wrappen. TGL: interessant ist, was nach außen
zum Programmierer sichtbar ist. WDE: möchte auf keinen Fall eine
Spaltung verursachen, Xenomai ist eine reine Firmenentscheidung.
Problem: Thema community, man kann sie nicht schaffen, eine Community
bildet sich! Versuchen, die verschiedenen Gruppen zu bündeln. Hier gäbe
es von den Xenomai Leuten sicher auch großes Interesse zur Mitarbeit.

BSP: man müßte zwei Schnittstellen bieten: 

- In Kernel Schnittstelle
- Userspace Treiber

Was wir brauchen sind Kochrezepte. 

MKL: zwei APIs: Ankabelung Treiber an Betriebssystem, und: wie setzt der
Programmierer auf das Betriebssystem auf. BSP: nein, man braucht User
Space API, weil nicht alle Protokolle offen implementiert werden dürfen
-> sie sind sich einig. 

RSC: Sichtweise auf Hardware? TGL: memory mapped I/O für
Prozeßabbild-organisierte Devices; z.B. bringt Ethercat Treiber das PA
einfach in Memory Bereich. User Space Treiber z.B. für Sercos, der Rest
passiert im User Space. TGL: für Userspace-Mapping braucht man eine
entsprechende Beschreibung; 3S wäre evtl. bereit, sein Konzept
einzubringen. Es gibt dort zwei Teile: a) über simple config files
beschreibbar b) komplexere Devices, die haben dann entsprechenden User
Space Support Mapper. 

RSC: wir müssen mit der vorhandenen kritischen Masse möglichst schnell
was erreichen. BSP: das User Space I/O Framework und Socket-CAN würden
sich hier anbieten. 

WGR: Ziel: was will man auf der SPS/IPC/Drives zeigen? Ideen: Live-CD,
Driver Writers Guide, Socket CAN. BSP: es gibt bestehende Applikationen,
man könnte die entsprechend messetauglich aufbereiten. RSC: hat sich der
Vorstand über Messen schon mal Gedanken gemacht? MWI: noch nicht, die
LIVE-CD ist erst mal im Fokus gewesen.

BSP: Kanotix Maintainer hat Interesse gezeigt an Realtime. TGL: Jack
Audio LIVE CDs.

Call for Papers für die SPS: läuft am 5. Mai aus. MWI: lieber was
verteilen für die Leute. D.h. wir infiltrieren die Messe in der
Breite...

TGL: haben I/O Framework, das man als Grundlage nehmen könnte.

WDE: für die Standardisierung kann man nicht einfach von oben kommen,
d.h. wir müssen die vorhandenen Dinge zusammensammeln und
zusammenbringen. KMA: sollte nicht die Message sein, daß man mit der
Standardisierung anfängt? TGL: Man kann nicht nur mit Papier anfangen,
die vorhandenen Ansätze sind ja auch schon aus den realen Anforderungen
entstanden. Es gibt für IIO schon Treiber für Sercos, Hilscher-Karte,
Onboard-I/O. KMA: OSADL muß mehr sein als eine Sammlung von
Existierendem. TGL: die Dinge müssen sich aus dem vorhandenen
entwickeln. Kann IIO Framework zur Verfügung stellen.

WGR: auf der CD sollten im Wesentlichen die Informationen über die Ziele
drauf sein. Demo: Problem ist reale Hardware. MWI: man kann viel mit
Simulation machen. Idee: billige Hardware?

CEM: Bis zum 23.05.2006 (Automation Day) ist die Webseite in einem
Zustand, daß dort die Webseiten der Projekte gehostet werden können

Derzeitige OSADL Projekte: 

- Realtime Preempt (TGL)

	* Webseite machen
	* User Mailingliste
	* umschalten mit Priorisierung, vanilla vs. preempt

	Next Steps:

	* HRT Patch für PowerPC, ARM kommt später. Ein Beispiel wäre
	  übernächste Woche verfügbar.

	* Wir brauchen einen Einführungsartikel. z.B. könnte ISG an
	  TGL die Frage stellen, wie man den Code portiert. Themen: wie
	  macht man Locking, wie macht man Thread, ... man nehme ..., 
	  was bedeutet welcher Schalter, warum ist die Ausgabe von 

- Live-CD (JAL)

	* englisch machen
	* Dokumentation reinbringen
	* Tests so machen, daß man mit und ohne 
	  RT laufen lassen kann (SCHED_OTHER)
	* CPU-Monitor

	Next Steps:

	* Scripte in SVN einpflegen
	* Angegungen einbringen
	* Ziel: Automation Day

- Industrial I/O Framework (BSP)

	Next Steps: 

	* Aufräumen
	* Patche gegen bekannte Kernel-Version, git Tree für
	  Entwicklungsversion
	* Zeitrahmen: zwei Wochen
	* Danach: Diskussion auf der Mailingliste

- Socket CAN (MKL)

	Next Steps:

	* Projekte von VW & Pengutronix bei Berlios zusammenführen
	* Treiber-Layer definieren
	* Error Handling, Treiber aufräumen
	* Filter-API, aber erst auf gemeinsamem Repository

- OPC Server (Thomas Rotfuß, Homag)

	* Ist ein Linux-Prozeß, Userspace, mit CORBA Interface. Damit
	  läßt sich jeder I/O dort einbinden und über OPC an Windows
	  bridgen. 

	* Interne API: hat Satznummern-System, dort werden die I/Os 
	  aus der Hardware in den OPC-Mechanismus gemappt.

	* Folgt dem OMG-Standard, nicht das Native OPC

	* Bringen Realtime ein auf Skala 500 ms Jitter

	Next Steps: 

	* Server wird ausgebaut / separiert
	* bis ca. Q3/2006
	* wollen komplettes I/O Abbild auf OPC-Semantik mappen

- OS9 Migrationsbibliothek (CEM)

	* Besteht aus drei Teilen: 

	  a) OS9 Filesysteme unter Linux
	  b) OS9 Library
	  c) OS9 Cross Entwicklung, gcc+wine (braucht OS9 Lizenz)

	Next Steps:

	* Library bis Q3/2006, es müssen N Versionen gemerged werden
	* Wenn's jemand braucht, kann man es vorher zur Verfügung
	  stellen.
	* Cross Umgebung steht zeitnah zur Verfügung

- Board Support Package Spezifikation (RSC)

	Next Steps:

	* Meeting RSC/CEM in 2. Maiwoche

Für jedes Projekt: Einstiegs-Webseite, Diskussionen finden zentral auf
der Mailingliste ag-automation statt. 

Mittagspause
============

IIO / RTDM
==========

Inwieweit kann man Treiber für RTDM _und_ Preempt-RT schreiben? Können
wir hier nicht klären. TGL: man möchte eigentlich, daß ein Programm auch
ohne Realtime läuft, wenn man keine Realtime braucht. MKL: RTDM
unterstützt nicht den kompletten Funktionsumfang von POSIX (z.B. kein
select(), poll(), fasync(), Signale). WDE: gibt es etwas vergleichbares
anderes? MWI: Erfahrungen mit RTAI waren, daß es am Anfang ganz gut
aussah, später aber die Architektur zusammengebrochen ist. RSC: was ist
das Problem, das RTDM lösen möchte? TGL: was es sicher lösen könnte ist
die Socket-Kommunikation (RTDM kommt von RTnet?). Die Frage ist, muß man
nicht-socket basierte Treiber auf das gleiche Modell abbilden? WGR: wenn
man RTDM benutzt, laufen nur noch RTDM Treiber. TGL: wenn es im Kernel
keine Möglichkeit gibt, den Netzwerkstack zu fixen, kann RTnet ja eben
auf RTDM aufsetzen. Gibt es andere RTDM User außer RTnet? (unklar). WGR:
bei Xenomai hat man immer das Problem, daß die RT-Domäne wächst, wenn
man mehr im Userspace haben möchte. TGL: wir müssen schauen, daß z.B.
das IIO Framework auch für Xenomai funktioniert, z.B. unten mit RTDM
Split von den Interfaces. Beispiel: Sercos-Treiber. Der Kernel macht nur
noch Interrupt und Aufwecken des Userspace Tasks. Hier sieht selbst der
Treiberschreiber nicht, wenn es unten noch einen Split gibt. Er
implementiert nur die Funktions-ops, die man irgendwo registrieren muß.
MKL: der Vorteil von RTDM ist, daß der API Umfang eingeschränkt ist. 

TGL: das Problem bei User Mode Treibern ist: Interrupt-Handling.
Greg-K-H sagt, von Mainline wäre ein großes Interesse da. Er hat eine
potentielle Lösung.  

BSP: was leicht lösbar ist: in /drivers/char gibt es 25000
Implementierungen von mmap(). Neue Treiber sollten dann eben die neuen
Infrastrukturen nutzen. Die Registrierung der Datenstruktur beim
Framework muß eben bei Xenomai/RT-Preempt gleich sein. 

RSC: was macht man mit dem Problem der preallozierten Buffer? TGL: das
ist eine separate Baustelle; im Zweifel nutzt man dann eben die
Möglichkeiten von RTDM (oder was auch immer). Message basierte Dinge
sind eine andere Baustelle!

TGL: stellt Konzept für IIO Framework vor. Allgemein: der Teil im Kernel
ist ziemlich klar, aber wie die Userspace-API gegen die
Support-Bibliothek aussieht und wie das Config-Interface ist, müssen die
Applikations-Firmen sagen! Der Userspace-I/O-Treiber basiert auf
Socket-Schnittstelle, File-Schnittstelle oder auf mmap().

Ethernetbasierte Feldbusse
==========================

RSC: gibt es Interesse, in dieser Richtung was zu tun? TGL: es gibt hier
ziemlich viele Möglichkeiten ... Fazit: momentan hat das OSADL überhaupt
keine Ressourcen, ein Konzept für industrielle Kommunikation zu
realisieren. RSC: das ist schlecht - Feldbusse sind heute ja irgendwie
ziemlich zentral. Wir verschieben das Problem auf später.

Testing
=======

- Testsuites gehen gegen vorhandene POSIX Schnittstellen, wenn der
  Test schiefgeht, fällt der Test halt durch.

- Auf verschiedenen Boards automatisiertes Regression Testing.

- Vorbereiten: die vorhandenen Tests & Lastszenarien automatisieren,
  dann kann man immer noch weitere Dinge dazu packen. 

- Die Ergebnisse müssen für jeden interpretierbar gemacht werden. 

- Scripting auf Bash bschränken. 

- POSIX Testsuite laufen lassen, für Code-Abdeckung 

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