Software Component Services for Embedded Real-Time Systems

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
The Component Object Model (COM)

• The most popular component model on Windows
• Basis for ActiveX and COM
• Separation of interface / implementation
• Interfaces specified in IDL
• Implementation in any programming language
• All interfaces and classes are registered with
  globally unique identifiers

IUnknown
I
C
1
C1
6
The Component Object Model (COM)
7
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

8
COM and Component Services
IUnknown
IUnknown
IUnknown
I
C
1
IC
2
IC
2
C
1
C
2
_
Proxy
C
2
C
2
_
Proxy
9
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

10
Component Services for ERTS
11
Component Services for ERTS
12
Example Logging Service
13
Example Logging Service

• ltapplicationgt
• ...
• ltcomponent name"myProject.C2"gt
• ltinterface name"IC2"gt
• ltservice type "Logging"/gt
• lt/interfacegt
• ...
• lt/componentgt
• ...
• lt/applicationgt

14
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

15
Component Services for Control

• Periodic execution
• Cascading of controller components and
  sensor/actuator interfacing components
• Possibly running at different sampling rates
• Fault detection and recovery
• Automatic management of power failure
• Quality of control

16
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

17
Prototype First Results

• Two prototypes developed by student projects
  (Thanks!)
• Each project with 6 members using 7501000
  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

18
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

19
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