Bicchi Antonio

From my angle, the messages I brought home from Finland were:

-) the duality between safety and best-effort is central in embedded systems. Embedded control has to relax the miopic guaranteed-performance obsession, but to do so we have to provide building blocks that encapsulate criticalities and contribute as components (Sifakis)

-) components for embedded control encapsulate physical systems, hence cannot be defined at the API level, must include timing: a component includes its controller. I would e.g. consider that an actuator, a sensor, or a filter are not components per se. A component is an input-output timed behaviour, hence it includes feedback if there is any. The physical hardware, including its temporal dynamics, are part of the component (Koptez)

-) what people in industry want is not more sophisticated algorithms, as they just want to reuse their PID/LQG controllers over and over. They want ways to be freed from detailed description of new parts (e.g., fuel pumps in an automotive) as to be able to plug them in the architecture they would love to have, and play with just a few tuning parameters. The real game is in defining the interfaces for the controlled physical components. Auto SAR is only addressing this problem at the level of SW/HW interfaces, do not take time and dynamics in consideration (insofar as we know), and is doomed to fail. (Kowaleski)

-) HRT is costly and cumbersome. Why do we need it? Because control cannot deal with asynchoronous operations of dynamical systems, basically. We need ways of separating parts that need HRT control, encapsulate them with local embedded control HW/SW, and allow higher level architectures to be built without such concerns - i.e., to go best-effort instead of guaranteed safe (Manninnen)

-) Symbolic control of physical plants is a possible way of studying these problems (Pappas, myself), and even more important as we realize the future of embedded control systems is wirelessly networked (Sastry). E.g.: Sinopoli filters with packet losses etc..

My opinion: insofar as we try to define components for control that consist of different parts of the system (sensors, actuators, filters,..), we will have no success. As it has happened often in control theory (cf. feedback linearization), the way out might be to look at composability properties achievable *with* feedback. I would only speak hence of "controlled components", defined as a timed i/o behaviour that includes any corrective/masking feedback you may need to make a given system appear as the architecture needs it to appear.

I think in my talk I tried to provide a summary of these ideas with the sketch of a Resource/C-Component/Requirement space to be learned.

Antonio