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





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



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



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



<<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



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





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





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



<<contract>>

CB

<<contract>>

CA

<<contract>>

CIFR

<<contract>>

CIFP



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 !

Documents

Explicit Connectors in Component Based Software Engineering for Distributed Embedded Systems