Embedded Components Component Infrastructures for embedded and small systems

1. Embedded Components Component Infrastructuresfor embedded and small systems Markus Völtervoelter@acm.orgwww.voelter.de

2. Contents • Introduction • Component Technologies • The Target Platforms • Current embedded systems architecture • Product Line Engineering and Generative Programming • Concepts of the Small Components Infrastructure • The Prototype • Example from the Automotive Domain

3. Contents • Introduction • Component Technologies • The Target Platforms • Current embedded systems architecture • Product Line Engineering and Generative Programming • Concepts of the Small Components Infrastructure • The Prototype • Example from the Automotive Domain

4. What is a component infrastructure • Most important principle: Separation of Concerns • Functional concerns of an application are factored into reusable Components • Technical concerns are provided by a standardized entity, a so-called Container • Components are accessed only through a Component Interface • Functionality of a Component is well defined, thus reusable.

5. What is a component infrastructure (II)

6. Component Infrastructures • System functionality is separated into components: • Components are then hosted in a container that handles technical concerns for them:

7. Component Infrastructures • A component has a well-defined and separated interface. • Container handles the lifecycle of components:

8. Component Infrastructures • To adapt the container to the specific components deployed in it, there usually needs to be a glue-code layer. • It is generated from annotations, that specify how the container should handle the component(s).

9. What is a component • “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.” • Definition by Szyperski • Additional properties of the kinds of Components we are interested in: • a component is coarse grained • principle of separation of concerns is employed • Components can be accessed remotely

10. Components in the Enterprise • There are several popular component architectures in the enterprise environment: • Enterprise Java Beans (EJB), a Java-only component model that is part of the Java 2 Enterprise Editition • Micorsoft's COM+, a widely-used component architecture limited to Windows operating systems. • CORBA Components (CCM), a component-extension to OMG's object request broker technology, • Many other component architectures that have been designed specifically for a specific system

11. Benefits: Why are they successful? • A Typical application structure: • database contains business data • processes that manipulate this data • usually in the context of transactions. • It is relatively easy to separate the functional from the technical concerns, and they can be implemented generically. • Standards and commercially available containers • People and their skills suit the seperation of concerns well • Standardized, well documented Programming Model

12. Contents • Introduction • Component Technologies • The Target Platforms • Current embedded systems architecture • Product Line Engineering and Generative Programming • Concepts of the Small Components Infrastructure • The Prototype • Example from the Automotive Domain

13. Target Platform Devices • We consider the following kinds of devices to be „small systems“: • Mobile Phones • PDAs, Organizers • Embedded computers, such as controllers or ECUs in vehicles orairplanes

14. Platform Characteristics • Non-homgeneity, almost every device is different (in contrast to enterprise systems) • Limited memory, only some hundred kB or some MB are available • Limited computing power because the device often contain only small processors • Limited electrical power because the device might be battery powered • Timing requirements can be more stringent: • No real time • Soft real time • Hard real time (out of scope!) • Network connection can either be permanent or intermittent

15. Contents • Introduction • Component Technologies • The Target Platforms • Current embedded systems architecture • Product Line Engineering and Generative Programming • Concepts of the Small Components Infrastructure • The Prototype • Example from the Automotive Domain

16. Typical Software Architecture Today • An OS Abstraction Layer hides some of the details of the underlying (realtime) operating system. • A more sophisticated approach,especially for product families, isthe use of a framework – provides reuse for repeating aspects.

17. Embedded Architecture with Components • Using a component containeris basically a framework thatuses separation of concernsand optionally generative techniques. • Reuse is simplified by only accessing components through their interfaces. • OS Abstraction Layer + Framework + Separation of Concerns + Reuse = Component Architecture

18. Goal: Componentized Embedded OS • In a last step, the container and the OS Abstraction Layer, as well as the operating system can be integrated to improve performance and reduce footprint even more.

19. Challenges for Components • Platform independent • The concepts should be independent of the OS and implementation language • Alternatively, the implementation should be done in a platform-independent programming language (such as Java) • Simple and lightweight. • A component infrastructure must be much simpler than e.g EJB or CCM • Focus on the really important pieces of functionality • Modular. • Underlying hardware and OS will not support all features provided by the embedded components infrastructure. • Thus, not all containers need to provide all possible features. • Container features must be „pluggable“.

20. Challenges for Components (II) • Reflective. • Components must know what their requirements are regarding the container and • containers must know what features they provide to the components • This is necessary to improve reliability • Network-aware. • Different network transport protocols must be pluggable without changing the component implementations (CORBA, Sockets, RMI, ...) • Performance. • It is not acceptable to impose big performance overheads into the system. • In contrast to enterprise systems, you cannot easily add more and more hardware resources.

21. Contents • Introduction • Component Technologies • The Target Platforms • Current embedded systems architecture • Product Line Engineering and Generative Programming • Concepts of the Small Components Infrastructure • The Prototype • Example from the Automotive Domain

22. Software Product Lines • Instead of developing one single system, development focuses on a family of related systems. Reasons: • different target platforms (operating system, middleware) • different quality of service (QoS) requirements, • potential for future growth • Systems are built from product-specific parts and reusable parts: the common platform • Creation of concrete systems should be done with the help of a (semi-)automatic assembly process • industrialized production of software • „build software like they build cars“

23. What is a software system family? • We consider a set of programs to constitute a family whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members. • Definition by Parnas, 1976 • A set of programs • related through their common properties • And distinguished through their specific properties

24. Product Line Engineering • Domain Scoping • Variability Analysis • Domain Structuring • Define common architecture • Define Production Plan • Define Building Blocks • Components • DSLs & Generators • Production Process

25. Example Family (Feature Diagram) • Example products: • An aircraft with a low wing, piston engine and made of metal, wood and cloth: Robin DR-400 • An aircraft with shoulder wing, no engine and made of plastic: ASW-27 • An aircraft with low wing, jet engine(s) and made of metal: Airbus A320

26. More features of Feature Diagrams • They can contain constraints on the combinations of features • They can define „names“ for specific combinations of features; feature groups • Features can be open: additional subfeatures can be added • Features can be incomplete: the subfeatures are not yet defined • Multiplicity of subfeatures can be added • And more...

27. Features and Binding Times • A feature diagram defines the common and variable aspects of a system. It has to be defined, when the variable aspects are fixed for a particular product.This is called binding time. • Usually, binding time has consequences on • flexibility • performance • code size • type safety • and: on the technique used to implement the variable aspect

28. Typical Binding Times • source time: manual programming, template parameters • compile time: function overloading, precompiler, template evaluation • link time: DLLs, class loading • run time: virtual functions, inheritance & polymorphism, factory-based instance creation, delegation • deployment/configuration time: component deployment (impl. for an interface), environment variables

29. Consequences of Binding Times

30. Generative Programming • Generative Programming …is a software engineering paradigm based on modeling software system families such that, given a particular requirements specification, a highly customizedandoptimized intermediate or end-product can be automatically manufactured on demand from elementary, reusable implementation components by means of configuration knowledge.Definition by Eisenecker & Czarnecki

31. Contents • Introduction • Component Technologies • The Target Platforms • Current embedded systems architecture • Product Line Engineering and Generative Programming • Concepts of the Small Components Infrastructure • The Prototype • Example from the Automotive Domain

32. Small Components and Product Lines • With respect to components and containers, there are two things that can be considered a family, and created using GP: • Components, their assembly and applications:This is the traditional way of using components & containers in the context of GP. • The container is a stable, fixed framework • Components are either (partly) generated and deployed, • or components are developed manually and GP provides selection, assembly, “wiring” and deployment in the container. • The container itself: This approach is used in embedded, resource constrained systems • The components are developed manually • The container is custom-generated “around” the components to provide resource-optimized management of technical concerns

33. Small Components and Product Lines (II) • Components are developed manually (or, later, generated) adhering to specific interfaces. • The container which provides the infrastructure to the components is automatically created, • Based on the

34. Small Components and Product Lines (II) • Components are developed manually (or, later, generated) adhering to specific interfaces. • The container which provides the infrastructure to the components is automatically created, • Based on a specification of required features • And the implicit requirements of the components that are configured to run in it. • With respect to the small components approach, the container is considered the product family, and it is specified, automatically created and assembled using generative techniques.

35. Useful Features for an embedded container • Scheduling • Interrupt Handling • Storage Service • Simple Event service • Generic driver interface • Pluggable transport • Security • Store and forward • Paging • ...

36. Related Technologies • Jini is a platform for spontaneous networking • Ninja is a project by the University of Berkeley that defines an architecture for intelligent network-centric services. • OSGi is a platform to manage services on small devices. Maybe it could be used as a basis. • WebServices defines an XML over HTTP based RPC mechanisms for use in the internet. • Apache SF project to build a framework for server apps • MQ everyplace is a version of the MQSeries messaging middleware that is available for small devices. • Java could be useful as a platform independent programming language. • TAO is a well-known and modular ORB that might be useful as a communication backend.

37. Contents • Introduction • Component Technologies • The Target Platforms • Current embedded systems architecture • Product Line Engineering and Generative Programming • Concepts of the Small Components Infrastructure • The Prototype • Example from the Automotive Domain

38. Problem Space, Feature Model • Additional Constraints: • Timer requires Signalling • Interceptors require Proxy • Signalling requires Signal Handling interface • Defaults: • No passivation

39. Problem Space - Configuration <ContainerConfig name="TestContainer" package="generated.smc"> <Components> <Component className="de.mathema.smc.test.PrintTextComponent" id="printerComponent" implementationClass="default"> <Config className="TextPrinter" package="generated.smc" /> </Component> <Instances> <SingleInstance asynch="false" id="signallerComponent" role="signaller"> <RuntimeConfig /></SingleInstance> <SingleInstance asynch="false" id="loggerComponent" role="systemLogger"> <RuntimeConfig /></SingleInstance> </Instances> </Components> <Interceptor className="de.mathema.smc.test.LogMethodCallInterceptor" name="logger" needsParams="true" needsPostinvoke="false"> <Target role="calculator"/> </Interceptor> </ContainerConfig> Component Instances Interceptors

40. Generative Approach for the Container • A system family needs to be created • We need to create a highly optimized solution, to be useful on the limited embedded devices. • We have a set of prebuilt components used by the Generator • We use code generation + parametrization

41. What does a component look like • A component has three interfaces • The Service Interface defines the operation the component offers to its clients • The Resource Interface specifies the resources the component needs to work correctly • The Lifecycle Interface is used by the container to manage an instance‘s lifecycle in the container

42. The Service Interface • The Service Interface is different for each component. • It defines all the operations the component provides to its clients. • It uses the suffix SI appended to the component name. • Example: A Calculator Component public interface CalculatorSI extends Service { public int add( final int a, final int b ) ; public int divide( final int a, final int b ) throws java.lang.ArithmeticException; public int minus( final int a, final int b ) ; public int times( final int a, final int b ) ; }

43. The Resource Interface • The Resource Interface is different for each component. • It defines all the resources required by the component. • Service Interfaces of other components • Any other resources provided by the container • It uses the suffix RI appended to the component name. • Example: A Calculator Component public interface CalculatorRI { public void setPrinter( final TextPrinterSI thePrinter ) ; public void setSignaller( final SignallerSIBase theSignaller ) ; }

44. The Lifecycle Interface • The Resource Interface is similar for each component. • It defines how the container handles components • It is called LifecycleInterface • Definition of the LifecycleInterface public interface LifecycleInterface { public void configure( ConfigCtx config ); public boolean configurationComplete(); public List getConfigLogMessages(); public void run(); public void shutdown(); }

45. Contents • Introduction • Component Technologies • The Target Platforms • Current embedded systems architecture • Product Line Engineering and Generative Programming • Concepts of the Small Components Infrastructure • The Prototype • Example from the Automotive Domain

46. Challenges in the automotive Domain • Typical modern vehicles consist of up to 50 Electronic Control Units (ECUs) • (and of course, some mechanics ) • They run complex, distributed software systems. • Software System Families can be defined on two levels: • There are different (software) configurations of a single ECU, because the hardware device they control (engine, brake system, air conditioning) varies. • There are different configurations of the vehicle itself – the collaboration of the ECUs and the vehicle as a whole can be considered a family

47. Challenges in the automotive Domain (II) • Robustness for the system is crucial, well-defined fail-safe modes must be defined (e.g. what happens when the ECU for the brake system crashes?) • Diagnosability: Diagnosing problems, failures and errors in a vehicle has become a complex and difficult task. • External diagnosis systems can only work efficiently, if the errors are well described internally by the software in the vehicle. This is really a big issue today! • Development of new ECU software packages must be very efficient, because the rate at which cars are improved and changed increases.

48. Some Benefits of in-vehicle components • Every component has a standardized diagnosis interface. • This allows component-based diagnosis and • Hierarchical diagnosis on a component tree • The component could also provide an interface to provide meta-information about itself and the resources it requires. • Currently this information is held outside the car in databases, and usually out-of-date. • A component knows ist container (i.e. a software system running on the hosting ECU) and can query the container for problems

49. Some Benefits of in-vehicle components • A component can be migrated to another container (aka ECU) in case of a failure. • If a vehicle feature should be distributed over several ECUs, a virtual component can be defined to serve as a facade. • A specific container can also help with diagnosis by e.g. checking timing requirements (a kind of debug mode for the car) • Studies are currently executed at several OEMs to investigate the feasibility of the approach.

50. Contents • Introduction • Component Technologies • The Target Platforms • Current embedded systems architecture • Product Line Engineering and Generative Programming • Concepts of the Small Components Infrastructure • The Prototype • Example from the Automotive Domain