Presentation is loading. Please wait.

Presentation is loading. Please wait.

Embedded Systems definition/characterization ➢ System Context is mainly technical ➢ Context actors are incoherent ➢ Non-functional/quantitative requirements.

Similar presentations


Presentation on theme: "Embedded Systems definition/characterization ➢ System Context is mainly technical ➢ Context actors are incoherent ➢ Non-functional/quantitative requirements."— Presentation transcript:

1 Embedded Systems definition/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.

2 Embedded Systems examples

3 Embedded Systems tongue control 2 X 1.5 cm flexible sampling 5*20*25=2500 Hz < 1000 kr 5 Hz datatrans wireless transmission rechargable batt., 24 hours

4 Analysis and Design of Embedded Systems COBRA (Concurrent Object Based RT Analysis) and CODARTS (Concurrent Object Based Design and Analysis of RT systems) Hassan Gomaa 1994

5 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

6 Embedded Systems Environment System Context Diagram (SCD) of Cordless Telephone System Terminators

7 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

8 Subsystems archetypes ➢ 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.

9 Subsystems Cordless Telephone Base station Handset

10 Subsystems Cordless Telephone- Handset Handset

11 Object types in problem domain ➢ I/O objects ➢ User role objects ➢ Control objects ➢ Data abstraction objects ➢ Algorithm objects

12 Objects Cordless Telephone

13 Interface Specifications Structured Data Dictionary

14 Behavioural Modelling (dynamics) State Transition Diagram (STD)

15 Behavioural Modelling Mini Specifiation

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

17 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

18 Behavioural Modelling (DECT example) hook Conn_Req Conn_Rep hook_sym_on Impatient Starts talking Ends conversation UserUserCtrlBase Station hook Conn_Rej

19 Behavioural Modelling (DECT example)

20 hook Conn_Req Conn_RejConn_Rep Conn_Rej hook_sym_on hook_sym_of Impatient Starts talking Receives beep UserUserCtrlBase Station

21 Behavioural Modelling (DECT example) Hook Beep / Timeout

22 Behavioural Modelling (DECT example) hook Conn_Req Conn_Rep hook_sym_on Impatient Starts talking UserUserCtrlBase Station beep Timeout

23 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

24 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) {

25 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

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

27 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.).

28 Task Structuring (Sequential Cohesion)

29 Task Structuring (Control Cohesion)

30 Task Communication mapping 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

31 Task Communication

32 Task Behavioural Specification timely - task specification Deterministic/non-deterministic: job invocations may be predicted Periodic/ Aperiodic Aperiodic/sporadic Pre-emptive/Non-preemptive: may be interrupted or not

33 Task Behavioural Specification timely / job specification Computation time: c Sporadic: Tmin >> c

34 Task Behavioural Specification real timeness hard realtime: d · Tmin realtime: d < 1 soft real time: E(C) < d, P(C


Download ppt "Embedded Systems definition/characterization ➢ System Context is mainly technical ➢ Context actors are incoherent ➢ Non-functional/quantitative requirements."

Similar presentations


Ads by Google