[ag-automation] [RFD] JTWG Automation Meeting

[Robert Schwebel]

OSADL JTWG Automation Meeting in Frankfurt/Main                rsc, 20070918-1
------------------------------------------------------------------------------

RSC Robert Schwebel, Pengutronix
MKL Marc Kleine-Budde, Pengutronix
MOL Michael Olbrich, Pengutronix
ETH Edouard Tisserant, Lolitech
MDU Mathias Duckeck, Kontron
MKR Michael Kremer, Homag
NNN N.N., Homag
DHE Dieter Hess, 3S
ABA Alexander Bauer, Phytec
KMA Klaus Maier, ISG
NNN
NNN

Agenda & Aims
-------------

The main topic of this JTWG Automation meeting is the current state and
further direction of the OSADL Fieldbus Framework (a better name still
has to be invented).

Configuration
-------------

- the framework needs to consider the following configuration schemes
  for bus nodes:

	* nodes with built-in configuration
	* config via network (autoprobe)
	* application (config by specification, EDS & friends)

- configuration: ISO 15745?

	powerlink
	ethercat
	canopen
	profinet

  seem to use it. Find out in which state the standard is. Nobody of the
  attendees knows if this standard is used more whidespread. Everyone
  seems to have it on his data sheets, but we don't know about if it
  is vapour ware or not. [sidenote: computer&automation has currently
  an article about FDCML & friends]

- we use xml for the config; if that's too slow, we can always invent
  some compiled format

Network Time
------------

- we need a model for network time
- IEEE1588 may be a provider of this, but the concept has to be generic

Object Model
------------

- RSC shows the current state of the OSADL Fieldbus Framework slides.
- there are two process variable namespaces: one on the fieldbus layer
  (fddi) and one on the application layer
- the mapping layer links them together
- mapping layer must convert PVs to engineering units
- DHE: in the application layer you want to have the same abstraction
  for example for a drive, no matter which bus it is connected to. RSC:
  yes, but this is a library issue, not a design issue for the stack.
  We have to agree on how an application base class for a drive looks
  like and have to make it uniform across all applications, but this
  is a pure application layer issue.

- We try to find out what a "drive" is:

	* it has a state machine
	* can do synchronisation
	* async notification

- RSC: we have to consider that the abstraction model does not only run
  on master nodes but also on slaves. How do the requirements for bus
  gateways look like: DHE: gateways usually do not handle time conditions

- we try to find out about when "events" do occur, e.g. in CANopen
  scenarios: the nodes do sample on sync, then send their data around.

- fddi must provide "events", which can be something like "all PDOs
  belonging to one sync have come in now (window)". The application is
  interested in the event that "all process variables are ready", but
  when this is can only be decided by the developer -> configuration.

- ETH: events may also be supplied by PV masks (i.e. a mask which is set
  when every pv in a pv_group is coming in; if all bits in the mask
  are set, fire an event)

- write use case: one block with 5 inputs wants to write one output;
  that block is there two times. When these two outputs are sent by the
  same out tpu, they have to be sent at the same time! -> config.

- so the mapping layer has to map

	a) process variables
	b) events

- we need to specify: this is an event, and when the event is arriving,
  this and that data has to be locked -> RSC and MOL made some example
  code after the meeting

- "locking" a tpu: one tpu comes in; one process maps it and may run for
  a long time; this memory is only freed when the last reader is finished
  with it. The new tpu comes into a new memory location anyway. The
  granularity for locking is minimum a tpu. Locking can be done with
  real locks, or lock-copy-unlock - work - lock-copy-unlock, or with
  RCU.

- MOL: for markers, we could write a "fake" backend which provides
  persistent pvs

Demonstrator
------------

The time is becoming very short until the SPS/IPC/Drives, so there will
probably be no chance to make a "larger" demonstrator for all of OSADL.
So we will focus on a corporate OSADL identity, plus rules how companies
can structure their demo systems.

Random ideas:

- commercial stacks

	Kontron uses nasty softing stack for profinet

- 3S:

	Kontron Panel PC, EtherCAT drive + I/Os
	AMK has CANopen drives! (ask hess)

- Pengutronix:

	ThinkIO, SocketCAN, FDDI

Kind Regards,
Robert Schwebel
-- 
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de