Embedded Systemsdefinition/characterization

➢ System Context is mainly technical➢ Context actors are incoherent➢ Non-functional/quantitative requirements

(time, reliability)➢ Technological limitations

(cost, size, power, CPU, memory, comm.)➢ Design involves both HW and SW➢ Distributed systems comprise multiple processors on different locations connected by thin communication channels.

Embedded Systemsexamples

Embedded Systemstongue control

• 2 X 1.5 cm

• flexible

• sampling 5*20*25=2500 Hz

• < 1000 kr

• 5 Hz datatrans

• wireless transmission

• rechargable batt., 24 hours

Analysis and Design of

Embedded SystemsCOBRA

(Concurrent Object Based RT Analysis)

and

CODARTS (Concurrent Object Based Design and Analysis

of RT systems)

Hassan Gomaa 1994

CODARTS steps

● Develop System Context Diagram (SCD)● Decompose into Subsystems● Modelling Objects in Problem Domain● Behavioural Analysis● Task Structuring● Task Prioritization● Task Communication● Task Behaviour Specification● Information Hiding● Integration of Task and Info. Hiding Views

Embedded SystemsEnvironment

System Context Diagram (SCD) of Cordless Telephone System

Terminators

Decomposition

● System ! Subsystems .. Subsystems .. ! Objects

● Subsystems partition terminators● Aggregate objects in problem domain may constitute

subsystem● Data stores owned by subsystem● Don’t split directly dependent functionality● Don’t split across heavy communication● Subsystems encapsulate similar functionality● Reflects locality in distributed systems● Decomposition reflects knowledge structure

in development team

Subsystemsarchetypes

➢ Realtime control: Implementing one or more real-time control loops (wait,input,compute,output) ➢ Real-time coordination: (coordinating multiple real time controls.) ➢ Data collection ➢ Data analysis ➢ Server (reacts to requests, does not initiate request)

User services

System services: File system, network system e.t.c.

SubsystemsCordless Telephone

Base station

Handset

SubsystemsCordless Telephone- Handset

Handset

Object typesin problem domain

➢ I/O objects

➢ User role objects➢ Control objects➢ Data abstraction objects➢ Algorithm objects

ObjectsCordless Telephone

Interface Specifications

Structured Data Dictionary

Behavioural Modelling (dynamics)

State Transition Diagram (STD)

Behavioural Modelling

Mini Specifiation

Event Flow Types

➢ Trigging: Commands to data transformations to perform some action which could be completed before reaching the target state. (blocking call) ➢ Enabling: Commands to datatransformation to perform actions with a duration beyond reaching the target state. (unblocking call) ➢ Disabling: Stop execution of action previously enabled.

Behavioural Modelling

➢ 1) Initial state diagrams suggested➢ 2) Use case traces performed➢ 3) In case of undesired behaviour ➢ 4) change state diagrams -> return to 2)➢ 5) Otherwise end

Program (state) dynamics determined from set of use cases

Behavioural Modelling(DECT example)

hook

Conn_Req

Conn_Rep

hook_sym_on

Impatient

Starts

talking

Ends conversation

User UserCtrl Base Station

hookConn_Rej

Behavioural Modelling(DECT example)

Behavioural Modelling(DECT example)

hook

hook

Conn_Req

Conn_Rej Conn_Rep

Conn_Rejhook_sym_on

hook_sym_of

Impatient

Starts

talking

Receives beep

User UserCtrl Base Station

Behavioural Modelling(DECT example)

Hook

Beep

/ Timeout

Behavioural Modelling(DECT example)

hook

hook

Conn_Req

Conn_Rep

hook_sym_on

Impatient

Starts

talking

User UserCtrl Base Station

beep

Timeout

Behavioural Modelling(Cautious approach)

➢ Break use cases up into nested non overlapping transactions➢ Let each transaction be recognizable from first message➢ Jump to state identifying transaction➢ Reject other transactions than nested ones when not idle

Behavioural Modelling(Implementation)

If(state==ST_NULL){ if(event==ConnReq) transmit(Conn_Req);}if(state==ST_CALL_INIT)....

switch(state){case(ST_NULL): switch(event) { case(ConnReq): transmit(Conn_Req); break; ...break;case(ST_CALL_INIT):...

...

Switch(state){case(ST_CALL_INIT): switch(sub_state) {

Task Structuring

➢ Enough tasks to facilitate the optimal processor utilization and parallel design.

➢ Not to many parallel processes in order to keep context switching down.

➢ Aperiodic/Active I/O objects are each associated to a process.(task).

➢ Periodic I/O objects with similar periods may be grouped into 1 process.➢ Periodic I/O objects where periods divide may be grouped into 1 task

Task Structuring(temporal cohesion)

long int counter;while(1){ wait(TimerSem); if(!counter%Period1) DeviceDriver1( ); if(!counter%Period2) DeviceDriver2( ); - - - if(!counter%PeriodN) DeviceDriverN( ); counter ++;}

Task Structuring(cohesion)

➢ Functional cohesion: nearly identical functions.

➢ Sequential cohesion: Is when a number of objects stimulate each other in a fixed sequence to execute. Then they may be collected into one task. (Sequential program.)

➢ Control cohesion: This type of cohesion has to do with the grouping of control transformations and data transformations that interact.

➢ - When data transformations are triggered by control transformations the 2 should be grouped into one task.➢ - When data transformations are enabled by a control transformation the 2 should be in separate tasks. (Both should be active when the disable stimulus is arriving.).

Task Structuring(Sequential Cohesion)

Task Structuring(Control Cohesion)

Task Communicationmapping internal event to message flow

Tightly coupled without reply: ack. Transmitted – unblocks sender

Tightly coupled with reply: sender blocked until reply ready

Loosely coupled: sender not blocked, queue may evolve

Loosely coupled with priority

Task Communication

Task Behavioural Specificationtimely - task specification

• Deterministic/non-deterministic: job invocations may be predicted

• Periodic/ Aperiodic

• Aperiodic/sporadic

• Pre-emptive/Non-preemptive: may be interrupted or not

Task Behavioural Specificationtimely / job specification

Computation time: c

Sporadic: Tmin >> c

Task Behavioural Specificationreal timeness

• hard realtime: d · Tmin

• realtime: d < 1

• soft real time: E(C) < d, P(C<d) ¸ Pd

• non realtime

Other definitions exist based on criticality of deadline misses or value/cost-functions