1. Software Component Services for Embedded Real-Time Systems Frank Lüders, Daniel Flemström, Anders Wall Presentation at the Working Session on Components and Services The Fifth Working IEEE/IFIP Conference on Software Architecture Pittsburgh, 9 November 2005

2. Overview • Software component models and services • Component services for embedded real-time systems • Expected benefits • Prototype: first results • Future work • Concluding remarks

3. Software Component Models • Enables component-based software development • Always define basic standards and services for component naming, composition, communication, etc. • Popular in the development of software for desktop applications and distributed information systems • May standardize domain-specific services, e.g. • for desktop applications: ActiveX and JavaBeans • for distributed information systems: COM+ and EJB

4. Component Models and ERTS • Software component models are not widely used for embedded real-time systems • Much research focusing on special-purpose models • Source code components (typically small) • Static configuration of systems (typically small) • Narrow application domains • E.g. Koala, PECOS, SaveCCM, etc. • Motivated by efficiency and predictability • Our approach • Binary components (inspired by COM and COM+) • Wider application domain (like commercial RTOSs)

5. COM and COM+ Component Services • COM defines interaction rules and basic services • COM+ extends COM with services typically used in distributed information systems • Examples include transaction handling, security, and persistent data management • Typically time-consuming and error-prone to implement for each component • Required services are specified by declarative attributes and provided by the run-time system through call interception • Implemented with “light-weight” proxy objects generated at run-time

6. COM+ and Component Services IUnknown IUnknown IUnknown I C 1 IC 2 IC 2 C 1 C C 2 2 _ _ Proxy Proxy C 2

7. Component Services for ERTS • Influenced by COM+ in two important ways • Services implement functionality that is common for the targeted domain and typically hard to write • Use proxy objects for call interception • Proxy objects are generated off-line on a development host (PC or workstation) • Based on component specifications and XML-based application configuration files • Downloaded and registered along with components • Component source code is not required

8. Component Services for ERTS

9. Component Services for ERTS

10. Example: Logging Service

11. Example: Logging Service <application> ... <component name="myProject.C2"> <interface name="IC2"> <service type ="Logging"/> </interface> ... </component> ... </application>

12. Examples of Services • Timing • Invocation time-out • Periodic execution (possibly multi-rate) • Synchronization • Mutex at interface/object/component level • Reader/writer policies • Monitoring • Execution-time measurement • Deterministic replay • Asynchronous invocation • Of synchronously implemented operations

13. Expected Benefits • Useful services make component-based development for embedded real-time systems more attractive • Placing error-prone functionality outside the components makes these simpler and more reliable • Leads to more reliable system if the platform is reliable • More reusable components • E.g., a component can be used in two different systems that share some functionality but use different synchronization policies • Services could be implemented by platform vendors

14. Prototype: First Results • Two prototypes developed by student projects (Thanks!) • Each project with 6 members using 750–1000 working hours (incl. requirement analysis, training, etc.) • Tools generate proxy for logging service, but are design to be easily extended with additional services • Provides initial “proof of concept”

15. Future work • Continue development of the prototype • Evaluate feasibility of the approach • Experiment with the prototype to determine resource overheads and effects on predictability • Evaluate usefulness of the approach • Replicated student projects with and without the prototype (controlled experiment) • Industrial project(s) with the prototype (case study) • Evaluate and extend the set of services • Hopefully with industrial/academic partners

16. Concluding Remarks • Approach differs from main research trend • Based on COM and influenced by COM+ • Well-known and accepted in industry • Proven in practice • Will require some resource overhead • Probably acceptable for many systems if development effort is substantially reduced • Empirical evaluation is needed • Feasibility, real-time requirements can be met • Usefulness, development effort is reduced