Explicit Connectors in Component Based Software Engineering for Distributed Embedded Systems
-
Upload
frances-gonzalez -
Category
Documents
-
view
30 -
download
0
description
Transcript of Explicit Connectors in Component Based Software Engineering for Distributed Embedded Systems
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 !