1 / 32

IT-606 Embedded Systems (Software)

IT-606 Embedded Systems (Software). Krithi Ramamritham S. Ramesh Kavi Arya KReSIT/ IIT Bombay. Software Design for Embedded System. Computational Models . What are embedded systems? . Computer (programmable part) surrounded by other subsystems, sensors and actuators

cayla
Download Presentation

IT-606 Embedded Systems (Software)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IT-606Embedded Systems(Software) Krithi Ramamritham S. Ramesh Kavi Arya KReSIT/ IIT Bombay Software Design for Embedded System

  2. Computational Models

  3. What are embedded systems? • Computer (programmable part) surrounded by other subsystems, sensors and actuators • Computer a (small) part of a larger system. • The computer is called a micro-controller Controller's function is : • to monitor parameters of physical processes of its surrounding system • to control these processes whenever needed.

  4. Design Challenges Embedded Systems are quite complex : 1. Correct functioning is crucial • safety-critical applications • damage to life, economy can result 2. Real-time systems • not only rt. outputs but at rt. time • imagine a delay of few minutes in pacemaker system 3. They are concurrent systems • System and environment run concurrently • multi-functional

  5. Design Challenges 4. They are Reactive Systems • Once started run forever. • Termination is a bad behavior. • Compare conventional computing (transformational systems)

  6. Design Challenges 5. Stringent resource constraints • compact systems • simple processors • limited memory • quick response • good throughput • low power

  7. Embedded System Design • involves HW and SW Design • Software for • Hardware for speed • Co-design of Software and Hardware • nonstandard HW - ASIC • System Partitioning - difficult step • Choice of programmable parts and ASICs

  8. Communication between ASIC and SW • Timing is crucial • Common languages for HW and SW • HardwareC, SpecC, SpecCharts, • Statecharts

  9. Design of Embedded Software • Systems are Complex • Classical design methodologies: • Informal requirements • Informal design • Formal final code • Verification of the code by Testing

  10. Totally inadequate for complex systems • Ambiguous, inconsistent • Thorough reviews required for early bug removal • Bugs often revealed late while testing • Several bugs remain undetected • Heavy redesign cost

  11. Model-based Development • Designs captured through models • Models describe behaviours of objects • Models are abstract and high level descriptions • Focus on one aspect at a time • Precise and executable

  12. Model-based Development • Models can be validated (Simulation, Formal Verification) • Models can be debugged and revised • Automatic generation of final code The paradigm Model - Simulate - Debug - Code - Generate Pardigm

  13. Modeling Languages • Various languages exist • Squential programming languages (C, C++), • assembly languages • State Machines, Statecharts, Esterel • Data FLow Diagrams, Lustre, Signal • Hardware description languages (VHDL, Verilog) • Unified Modeling Languages (UML)

  14. Modeling Languages Choice of languages depend upon the nature of computations Seq. programming models useful for standard computations But not suitable for embedded software

  15. Reactive Systems • Standard Software is a transformational system • Embedded software is reactive I O T. S.

  16. Figure 1: Transformational vs Reactive R. S.

  17. ES features • Reactive • Concurrency (at least system and environment) • Event driven • Events at unpredictable times • Timely response (hard and soft real time) • Criticality Conventional models inadequate

  18. Finite State Machines Model • One of the well-known models • Intuitive and easy to understand • Pictorial appeal • Can be made rigorous • Standard models for Protocols, Controllers, HW

  19. An Example Model • Elevator Controller

  20. An Example Model • 3- floor elevator, Si– in floor i • ri - request from floor i • uj,dj - up/down by j floors • This machine is nondeterministic • In S 2 when requests r1 and r3 arrive. • Non-determinism due to abstraction • More than one behaviour for a given input

  21. Features of FSMs • Finite number of states • Initial state • No final state (reactive system) • Non determinism (result of abstraction) • Edges labeled with events • Behavior defined by sequences of transitions • Rigorous semantics • Easy to simulate and debug • Code generation possible

  22. C-implementation main() enum floors f1,f2,f3; enum State first,second,third; enum bool ff,tt; enum floors req, dest; enum bool up, down = ff; enum State cur_floor =first;

  23. C-implementation req = read_req(); while (1) switch (cur_floor) Case first: if (req == f2) up = tt; dest = f2; else if (req == f3) up = tt; dest = f3; else up == ff; Down = ff;; break; case second: if (req == f3) up = tt; dest = f3; else if (req == f1) up = ff; down = ff;;

  24. C-implementation dest = f1; else up == ff; down = ff;; break; case third: if (req == f2) up = ff; down = tt; dest = f2; else if (req == f1) up = ff; down = tt; dest = f1; else up == ff; down = ff;; break; ; req = read_req();

  25. Suitability of C • C is not natural for such applications • events and states all modeled as variables • states are implicit (control point decide the states) • no abstract description possible • too low level and commitment to details etc. • avoided for high level designs and protoypes • Exercise: Find the problems in this design and improve

  26. Statecharts • FSMs fine for small systems • FSMs are with no structure • Large descriptions difficult to understand • Statecharts (Harel) • Hierarchical States • Concurrent Machines • Communication among concurrent components • UML statecharts

  27. Statecharts Example

  28. Extensions to Statecharts • various possibilities explored • adding code to transitions • to states • complex data types and function calls • SpecCharts, SpecC, SynchCharts • State Simulink

  29. Other Models • Synchronous Reactive Models • useful for expressing control dominated application • rich primitives for expressing complex controls • Esterel - Esterl Studio • More on this later

  30. Other Models • Data Flow models • useful expressing numerical computations • Lustre, Signal • SCADE • Discrete Event Models • VHDL, Verilog

  31. Red Summary • Various models reviewed • Sequential programming models • State Machines • Hierarchical and Concurrent State Machines • Each model suitable for particular applications • State Machines for event-oriented control systems • Sequential program model, data model for function computation

  32. Hierarchical machines for complex control behaviours • Choice should be made based upon application • In general, mixture of models required • Ptolemy tool, U. Berkeley

More Related