explicit connectors in component based software engineering for distributed embedded systems
DESCRIPTION
Explicit Connectors in Component Based Software Engineering for Distributed Embedded Systems. Dietmar Schreiner , Karl M. Göschka Vienna University of Technology Institute of Information Systems Distributed Systems Group 2007. Overview. This talk is about - PowerPoint PPT PresentationTRANSCRIPT
Explicit Connectors in Component Based
Software Engineering for Distributed
Embedded Systems
Dietmar Schreiner, Karl M. Göschka
Vienna University of TechnologyInstitute of Information Systems
Distributed Systems Group
2007
2/21
Overview
• This talk is about– Component Based Software Engineering
• components• connectors• contracts
– Embedded Systems Software• distributed• dependable • resource constrained
– Software Development Process• Model Driven Development• Validation and Verification of Composition
Models
3/21
Contribution
• We show – how to simplify the development of
component based distributed embedded applications by introducing explicit component connectors within model driven SE (UML 2).
– how to support validation of communication properties at model level.
– which types of contracts are required for model level validation of communication within composed structures.
4/21
Outline
• Overview of the Automotive Embedded Systems Domain.
• Component Based Software Engineering and Model Driven Development for distributed embedded systems.
• Contract Types in Composition Models.
• Example Composition with Explicit Connectors and Contracts.
5/21
Automotive Embedded SystemsOverview
• Today's vehicle networks are truly distributed electronic systems (70+ nodes (=ECUs) [1]).
• Cars contain numerous (10+) heterogeneous time or event driven bus systems
– CAN, LIN, FlexRay, MOST
• x-by-wire• steering aids, ABS, ESP(DSC)• remote window and lock control• engine control• airbag control• navigation systems• entertainment systems
[1] P. Hansen. New s-class mercedes: Pioneering electronics. The Hansen Report on Automotive Electronics, 18(8):1–2, October 2005.‘
6/21
Automotive Embedded SystemsTypical Properties
• Software is mission critical– highly dependable– hard real-time– typically statically scheduled and bound
• Lifetime is rather long (10-14 years)– modular design– exchangeable components (modules)
• Systems are produced in high quantities (56.3 million cars in 2005)– costs have to be small– bug fixes are extremely expensive
7/21
Outline
• Overview of the Automotive Embedded Systems Domain.
• Component Based Software Engineering and Model Driven Development for distributed embedded systems.
• Contract Types in Composition Models.
• Example Composition with Explicit Connectors and Contracts.
8/21
Component Based Software EngineeringOverview
• Components are considered to be– trusted element of execution– with a well defined usage
description• contracts
– component contracts– interface contracts
– conforming to a component model• interaction standard• composition standard• deployment standard
<<component>>Name
required services
provided services
Interfaces
<<contract>>* Requirements* Provisions
<<component>>Name
required services
provided services
Interfaces
<<contract>>* Requirements* Provisions
<<contract>>* Requirements* Provisions
1 2
2
• CBSE is a well known paradigm in classical software engineering.
– Applications are built by • assembling components • deploying composed structures within a system environment
<contract type="RI" id="CIFR"> <interface type="API" id="0"> <operation id="exampleService"> <param idx="0" type="void"/> <result type="void"/> <wcet t="0.05s"/> </operation> </interface> </contract>
<contract type=“PI" id="CIFP"> <interface type="API" id="0"> <operation id="exampleService"> <param idx="0" type="void"/> <result type="void"/> <wcet t="0.01s"/> </operation> </interface> </contract>
9/21
Component Based Software EngineeringComponent Composition
• Association (connection) of provided and required interfaces– interaction and communication implicit– validation is typically an interface type check, sometimes also a protocol check
• Distributed Interaction (Communication)– Fat Components– Light Weight Components + Middleware
<< component >>Client
< Interface >
<< component >>Server
<< component >>Client
<< component >>Server
Communication Middleware
Virtual Function Bus
Adapter
10/21
Component Based Software EngineeringCOMPASS[2] Metamodel
PROCEDURAL_INTERFACE
PORT
+id
INTERFACE
+version+id
COMPONENT
+version+id
CONNECTOR
+id
ASSEMBLY
+id
DATA_INTERFACE
PROVIDED
0..*
1
1..*
1
REQUIRED
0..*
1
PROVIDED
*
*
REQUIRED
*
*
REQUIRED 0..*
1
1
1
0..*
1 2
1
PROVIDED
0..*
1
0..* 1
[1] COMPASS – Component Based Automotive System Software, http://www.infosys.tuwien.ac.at/compass‘
11/21
Component Based Software EngineeringExplicit Connectors
• First class architectural entities embodying component interaction– life cycle differs from that of a component
• at composition time connectors are abstract representations of interaction properties
• connectors “materialize” after the components’ deployment has been specified
– connector fragments are component like artefacts
• Hide matters of communication and distribution from the application components– simplifies application components– application development no longer requires detailed
communication subsystem know-how, when using OTS connector
– communication properties are bound to the connectors
12/21
<< component >>Client
<< component >>Server
<<contract>>
CB
<<contract>>
CA
<<contract>>
CIFR
<<contract>>
CIFP
IF<< connector >>Fragment CFA
<< connector >>Fragment CFB
Physical Boundary
Explicit Connector
IF<< component >>
Client<< component >>
Server
<<contract>>
CB
<<contract>>
CA
<<contract>>
CIFR
<<contract>>
CIFP
IF<< connector >>Fragment CFA
<< connector >>Fragment CFB
Physical Boundary
Explicit Connector
<<contract>>
CIFP’
<<contract>>
CIFR’<<contract>>
CCFA
<<contract>>
CCFB
IF
Component Based Software EngineeringConnector Fragmentation
• Connectors are fragmented if…– components are deployed over process/address space boundaries.– components are deployed over different nodes.
• Separation into connector fragments is referred to as deployment anomaly.
• Emerging contracts provide more detailed communication properties
<< component >>A
<< component >>B
<<contract>>
CB
<<contract>>
CA
<<contract>>
CIFR
<<contract>>
CIFP
Physical Boundary
IF
13/21
Component Based Software EngineeringExplicit Connector Example (RPCA)
<< component >>BUS Sender
<< component >>BUS Receiver
<< component >>Protocol Handler
<< component >>Marshalling
<< component >>Demarshalling
<< component >>TimeService
<< component >>Scheduler
<< stateless >> << stateless >>
<< singleton >> << singleton >>
<< singleton >>
<< singleton >>
<< component >>Request Manager
IConnectorCall
IConnectorCallback
IConnectorSender
IConnectorReceiver
14/21
Outline
• Overview of the Automotive Embedded Systems Domain.
• Component Based Software Engineering and Model Driven Development for distributed embedded systems.
• Contract Types in Composition Models.
• Example Composition with Explicit Connectors and Contracts.
15/21
Component Based Software EngineeringContracts
• Specify provided and required attributes of associated model elements.
• Five main categories:– Component Contract
• e.g. memory footprint, ECU restrictions– Interface Contract
• e.g. operation signatures, temporal properties of operations
– Port Contract• e.g. behavior protocols
– Connector Contract• e.g. resource requirements, channel attributes (latency,
…)– Platform Contract
• e.g. bus timing (in time-driven busses), ECU attributes
16/21
Component Based Software EngineeringContracts
• Modeled as artifacts associated with related model elements
contract
interface_contractoperation_contract
timed_operation
**
• Simple type hierarchy for contracts allows easy extensions (e.g. interface contracts)
• Content of contracts is not predefined. COMPASS contracts are XML documents.
17/21
Outline
• Overview of the Automotive Embedded Systems Domain.
• Component Based Software Engineering and Model Driven Development for distributed embedded systems.
• Contract Types in Composition Models.
• Example Composition with Explicit Connectors and Contracts.
18/21
ExampleComposition
<< component >>A
<< component >>B
<<contract>>
CB
<<contract>>
CA
<<contract>>
CIFR
<<contract>>
CIFP
IF
Component Contract
• Memory Usage• ECU restrictions
Component Contract
• Memory Usage• ECU restrictions
Interface Contract
• Interface Type• Operation Signatures• WCET
Interface Contract
• Interface Type• Operation Signatures• WCET
<contract type="RI" id="CIFR"> <interface type="API" id="0"> <operation id="exampleService"> <param idx="0" type="void"/> <result type="void"/> <wcet t="0.05s"/> </operation> </interface> </contract>
<contract type=“PI" id="CIFP"> <interface type="API" id="0"> <operation id="exampleService"> <param idx="0" type="void"/> <result type="void"/> <wcet t="0.01s"/> </operation> </interface> </contract>
19/21
ExampleDeployment Specification
<<component>>:A
<<component>>:B
ECU1 ECU2
<<contract>>
CECU1
<<contract>>
CECU2
BUS
<<contract>>
CBUS
Platform Contract
• Memory Provision• ECU specification
Platform Contract
• Memory Provision• ECU specification Platform Contract
<contract type="P" id="CBUS"> <bus id="0"> <buscycle_length t="0.1s"/> <slot_length t="0.02s"/> </bus></contract>
20/21
ExampleConnector Transformation
<< component >>Client
<< component >>Server
<<contract>>
CB
<<contract>>
CA
<<contract>>
CIFR
<<contract>>
CIFP
IF<< connector >>Fragment CFA
<< connector >>Fragment CFB
Physical Boundary
Explicit Connector
<<contract>>
CIFP’
<<contract>>
CIFR’<<contract>>
CCFA
<<contract>>
CCFB
IF
Connector Contract
<contract type="C" id="CCFA"> <connector type="RPC"> <response time="1.0 cycle"/> <WCET t="0.01s"/> </connector>
</contract>
Calculated Interface Contract
Provides properties of the server component but extends them by the communication subsystem’s constraints.
• WCET of operation at server is 0.01s• WCET of connector fragments is 0.01s• BusCycle length = 0.1s (has to be consumed)• •provided execution time = 0.12s !! Violation of Contract !
21/21
Conclusion• The introduction of explicit connectors
– allows the usage of OTS embedded connectors encapsulating communication logic
• eliminates needs for heavy weight middleware• simplifies the development of application components• provides information on required system resources
– allows a model level validation of compositional constraints beyond simple type checks
• Future Work– Generate custom tailored middleware from application
models and connector building blocks. – Develop a more precise meta-model for contracts.
Thank You !