What are Embedded Systems? 1 Lecture 1 Introduction to Embedded Systems & Software Roopa Rangaswami October 9, 2002 Embedded systems are computer systems that monitor, respond to, or control an external environment Environment connected to system through sensors, actuators and other I/O interfaces Embedded systems must meet timing & other constraints imposed on it by environment Also called real-time or reactive systems - terms used interchangeably
Examples of Embedded Systems Vehicle systems for automobiles, subways, aircraft, railways Process Control for power & chemical plants Medical facilities for automatic patient care, air traffic control & remote bank accounting Military uses - tracking, command & control Telephone, radio & satellite communications Household systems for monitoring & controlling appliances 2 Generalised Embedded System Computer is interfaced directly to real-world physical equipment Physical equipment controlled through regularly sampling measurement devices Required - real-time clock, information about system state changes, operators console System software modules reflect physical nature of environment module for physical control of devices module to record system changes module to retrieve & display changes module to interact with operator 3
4 Embedded vs. Conventional Systems - Hardware 5 Computer hardware for embedded applications consists of fairly standard components - e.g. processors memory units buses & peripherals plus real-time I/O devices, e.g. sensors & actuators
Embedded vs. Conventional Systems - Software (1) Embedded software differs from conventional software: (1) program must be both logically & temporally correct software must satisfy timing assertions on relations over relative & absolute times - e.g. deadlines - a limit on (relative or absolute) time when a computation must complete Distinction between hard & soft real-time systems Hard - must meet timing constraints, else system fails; e.g. system that controls vertical motion of a lift Soft - considered successful despite missing some timing constraints; performance may deteriorate; e.g. Failed phone connection 6 Embedded vs. Conventional Systems - Software (2) (2) Embedded software must deal with inherent physical concurrency - part of the external world to which they re connected Signals from environment can arrive simultaneously disjoint but parallel activities may be monitored/controlled by a single computer system & output signals may need to be emitted at the same time (timing constraints) Complexity of system design increases because of combination of concurrency and timing problems 7
Embedded vs. Conventional Systems - Software (3) (3) Reliability & Fault Tolerance issues are particularly significant Reliability - measure of how often a system will fail, or the probability that it will perform correctly over a given period of time However, no system is perfectly reliable, so must be able to cope with failures - e.g. mission failures, loss of human life or money can be very costly Fault Tolerance - concerned with recognising & handling failures; avoid failures where possible, else fail gracefully with as little cost as possible 8 Embedded vs. Conventional Systems - Software (4) Criticality - measure of the cost of failure Higher the cost of failure, the more critical the system e.g. - aircraft or nuclear power plant controller are highly critical systems Differentiate hardness & criticality (often go together) - not meeting a constraint may cause system failure, but failure may not be critical 9
10 Embedded vs. Conventional Systems - Software (5) (4) Most conventional computer systems are general-purpose - i.e. run several applications at the same time Embedded systems, on the other hand, are application-specific & often stand-alone - all s/w including OS is tailor-made for the particular system (5) Many embedded systems have a human operator who interactively controls & monitors it - human-machine interface design must prevent errors & confusion Embedded vs. Conventional Systems - Software (6) (6) Testing & Validation - due to high costs of failures, it is often impossible to test & validate systems in their environments, but rely on simulations testing of subsystems careful specifications & comprehensive analysis of designs run-time procedures for fault detection & handling 11
12 Interaction with Hardware Devices Embedded systems require components to interact with environmental devices through sensors & actuators Computer interface is through input & output registers - operation is device & system dependent Devices can also generate interrupts to signal the processor Control of devices must often be direct (not through OS) because of time-criticality Interfacing to devices considered later Requirements of Embedded Hardware Tight timing constraints often require high speeds of operation of components Run-time behaviour must be predictable to enable s/w designers to predict applications behaviour Hardware must be reliable & fault-tolerant either to prevent, or predictably handle costly errors Memories, caches, processors, controllers & I/O devices need to be program accessible & controllable 13
14 Generic Embedded Hardware Configuration (1) Generic Embedded Hardware Configuration (2) 15 Comprises several nodes connected by a comms. network Significant - presence of sensors, actuators, displays, precise clocks & timers For the purpose of timing prediction, behaviour of virtual memories, instruction & data caches must predictable System should provide both polling & priority interrupts for sensors, actuators & I/O devices
16 Generic Embedded Hardware Configuration (3) Resource sharing between processors & I/O devices can cause unpredictable performance Programs can be organised so that processors & I/O don t access same memory locations simultaneously More difficult to guarantee deterministic timing over a comms. network Message transmission times unpredictable because of transmission path or medium multiplicity, or shared network H/w reliability within and between nodes obtained through redundancy Software Life-cycle of Embedded Systems Life Cycle - stages from initial specification to final deployment & use Classified into six sequential phases or tasks 1. Concept - determination of project needs & goals 2. Requirements - what the software must do 3. Design - how s/w will meet its requirements 4. Implementation - programming the application 5. Testing - set of independently developed test cases are used to verify that system meets requirements 6. Maintenance - additions, deletions & modifications due to changing conditions Feedback loops connect the phases 17
18 Concept Phase Determine project goals & needs - driven by customer input, technology changes & marketing decisions Includes feasibility studies By-product of stage - often a white paper, detailing what to build, and justifying the project & its feasibility Requirements Phase (1) Formal requirements specification about interfaces, functions, timing & physical constraints, such as, mass, power, voltage, etc. Does not specify how to meet requirements, but may specify budget & schedule Test requirements committed to a test plan (used to generate test cases in stage 5) 19 Forms the contract if customer & designer are different
20 Requirements Phase (2) Functional Requirements - features which can be tested by exercising the system Non-functional Requirements - specification about processor type, implementation language, methodology, version control, documentation, maintainability, modularity, schedule, etc. Chief goals of phase - define h/w & s/w interfaces write requirements document write test plan prepare project schedule & budget Design Phase Converts requirements document into a detailed specification called detailed design document Specifies how requirements are to be met by partitioning functional features into h/w or s/w modules Design phase often finds problems in the requirements document, such as, conflicts, redundancies or technological difficulties Requirements document may need to be modified - e.g. exempt certain requirements 21
22 Design Phase - Major Tasks Partition system into modules whose implementation is clear Allocate modules to h/w or s/w Prepare detailed design document Develop specific test cases Implementation Phase Implement modules detailed in design phase - programs for s/w, circuits for h/w - implemented concurrently Phase ends when all modules implemented & integrated Tools (e.g. CASE) can be used to manage software development 23 Major Tasks - Code s/w & build h/w modules Debug s/w & h/w and integrate modules Developed automated test cases
24 Testing Phase Testing, in order to debug software, occurs throughout implementation phase Testing phase is a formal step where a set of independently developed test cases are used to verify that system meets its requirements System cannot be changed in this phase - if it fails, has to be redesigned and then completely re-tested Phase consists of: 25 Maintenance Phase Product deployment Customer support Continuing system error correction Release control Phase ends when product is no longer required Main tasks in this phase - perform system validation & prepare test reports