Software Engineering for Embedded Systems Lecture 12.

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13Slide 1 Chapter 13 Real-time Software Design.
Advertisements

1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Real-time Software Design IS301.
Real-time Software Design
Real-time software Sommerville, Hfst. 13. Sommerville, Ch. 132 Real-time systems A real-time system is a software system where the correct functioning.
Chapter 20- Embedded Systems
Chapter 2 Real-time software design
Chapter 20- Embedded Systems Lecture 1. Topics covered  Embedded systems design  Architectural patterns  Timing analysis  Real-time operating systems.
In this presentation you will:
Figures – Chapter 20.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15 Slide 1 Real-time Systems 2.
Figures – Chapter 5. Figure 5.1 The context of the MHC-PMS.
Real-time Software Design
Chapter 13 Embedded Systems
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Real-Time Systems and Programming Languages
Chapter 5 – System Modeling 1Chapter 5 System modeling.
Chapter 5 System modeling Chapter 5 – System Modeling Lecture 1 1.
EMBEDDED SOFTWARE Team victorious Team Victorious.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15 Slide 1 Real-time Systems 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
1 Reference architectures u Reference models are derived from a study of the application domain rather than from existing systems u May be used as a basis.
CS451 Introduction to Software Engineering Behavioral Modeling.
Software Engineering 8. System Models.
Chapter 5 – System Modeling
Chapter 5 – System Modeling 1Chapter 5 System modeling.
Chapter 5 – System Modeling Lecture 1 1Chapter 5 System modeling.
Chapter 5 – System Modeling
1 Embedded Systems Development. 2 Topics covered  Embedded systems design  Architectural patterns  Timing analysis  Real-time operating systems.
Real-Time Software Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
 Dr. Syed Noman Hasany 1.  Review of known methodologies  Analysis of software requirements  Real-time software  Software cost, quality, testing.
EMBEDDED SYSTEMS 9 April 2013 William W. McMillan.
Lecture 6 Systems Modeling
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 16 System Architecture and Design II.
Chapter 5 – System Modeling
1 소프트웨어공학 강좌 Chap 11. Real-time software Design - Designing embedded software systems whose behaviour is subject to time constraints -
CS4730 Real-Time Systems and Modeling Fall 2010 José M. Garrido Department of Computer Science & Information Systems Kennesaw State University.
EEL Software development for real-time engineering systems.
Chapter 5 – System Modeling 1Chapter 5 System modeling CS 425 October 13, 2011 Ian Sommerville, Software Engineering, 9 th Edition Pearson Education, Addison-Wesley.
 Chapter 5 System Modeling 1. Context Model  Shows context (environment) of proposed system  Other software  People  Roadmap of major areas to consider.
Reference: Ian Sommerville, Chap 15  Systems which monitor and control their environment.  Sometimes associated with hardware devices ◦ Sensors: Collect.
Chapter 5 System Modeling (2/2) Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Slide 1 Chapter 11 Real –time Software Designs. Slide 2 Real-time systems l Systems which monitor and control their environment l Inevitably associated.
EKT 424 Real Time System 1.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Chapter 5 – System Modeling Chapter 5 System Modeling1 CS 425 October 20, 2015 Ian Sommerville, Software Engineering, 10 th Edition Pearson Education,
©Ian Sommerville, Robin Abraham 2004CS 361, Summer 2004 Slide 1 Real-time Software Design.
Real-time Software Design King Saud University College of Computer and Information Sciences Department of Computer Science Dr. S. HAMMAMI.
CS4730 Real-Time Systems and Modeling Fall 2010 José M. Garrido Department of Computer Science & Information Systems Kennesaw State University.
Chapter 5 – System Modeling 1Chapter 5 System modeling CS 425 October 18, 2010 Ian Sommerville, Software Engineering, 9 th Edition Pearson Education, Addison-Wesley.
Chapter 21– Real-time Software Engineering 04/12/2014Chapter 21. Real-time Software Engineering1.
Real-time Software Design Chapter 15 of Ian Sommerville’s Book on Software Engineering.
Chapter 5 – System Modeling Chapter 5 System Modeling130/10/2014.
Software Engineering Lecture 6 – System Modelling
Chapter 5 – System Modeling Lecture 9 Section A 27/4/2015 Section B 29/4/2015 1Chapter 5 System modeling.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15 Slide 1 Real-time Software Design.
Real-time System Definition A real-time system is a software system where the correct functioning of the system depends on the results produced by the.
Embedded Real-Time Systems Processing interrupts Lecturer Department University.
Embedded software / Real-time Software Engineering 1.
Real-time Software Design. Objectives l To explain the concept of a real-time system and why these systems are usually implemented as concurrent processes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
Real-time Software Design
Real-time Software Design
Real-time Software Design
Chapter 5 – System Modeling
Real-time Software Design
Real-time Software Design
Real-time Software Design
CS 501: Software Engineering Fall 1999
CS310 Software Engineering Dr.Doaa Sami
Presentation transcript:

Software Engineering for Embedded Systems Lecture 12

Keep in mind The first and most important rule of real time system design is to know: –The worst case performance requirements of each activity –ONLY then select the right implementation (CPU, hardware design, and firmware organization). It's important to think in the time domain as well as in that of the conventional procedural. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST2

Embedded Software Computers are used to control a wide range of systems: –Simple domestic machines, Games controllers, Entire manufacturing plants. Their software must react to events generated by the hardware and, often, issue control signals in response to these events. –The control signals results in an action, like initiation of a phone call The software in these systems is embedded in system hardware, often in read-only memory, and usually responds, in real time, to events from the system’s environment. –Software system has a DEADLINE for responding to external events –The time constraints have to be considered during planning, design, implementation and testing phases. 3Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST

Responsiveness in Real Time Responsiveness in real-time is the critical difference between embedded systems and other software systems (non-real time systems), such as: –Information systems, web-based systems or personal software systems. Data processing is main process –For non-real-time systems, correctness can be defined by: Specifying how system inputs map to corresponding outputs that should be produced by the system. –In a real-time system, the correctness depends both on the response to an input and the time taken to generate that response. If the system takes too long to respond, then the required response may be ineffective. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST4

Few Definitions Observe “ Time is inherent in the definition” –A real-time system is a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced. –A soft real-time system is a system whose operation is degraded if results are not produced according to the specified timing requirements. e.g. Live Video Streaming –A hard real-time system is a system whose operation is incorrect if results are not produced according to the timing specification. e.g. Pacemakers, Airplane control systems Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST5

Embedded system characteristics Embedded systems generally run continuously and do not terminate. –Start when the hardware is switched on, and execute to the hardware is switched off Techniques of reliable software engineering will be used RTS may include update that support dynamic reconfiguration Interactions with the system’s environment are uncontrollable and unpredictable. –In interaction systems, The pace of interaction is controlled by: The system Limiting the user options and The event to be processed are known in advanced –In Real time embedded system, system may be able to respond to unexpected events at any time. Design of the system should be based on concurrency, with several processes executing in parallel. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST6

Embedded system characteristics There may be physical limitations (e.g. Power available to the system) that affect the design of a system. –Limitations may generates requirements (e.g. conserve power, prolong battery) for the embedded software, –To limit the size the software may perform some hardware functions Direct hardware interaction may be necessary. –May need to interact with wide range of hardware without having separate device drivers Issues of safety and reliability may dominate the system design. –Dependability is critical in RTS, so the design must ensures the safety critical behaviour at all times –Only tried and tested techniques are suggested Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST7

Embedded System Design The design process for embedded systems is a systems engineering process that has to consider, in detail, the design and performance of the system hardware. –Part of the design process may involve deciding which system capabilities are to be implemented in software and which in hardware. –Low-level decisions on hardware, support software and system timing must be considered EARLY in the process. Top-down (traditional approach of design) may not work here Limit the flexibility of the system designers and may mean the additional software functionality to be added, such as battery and power management has to be included in the system. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST8

Reactive systems Embedded systems are reactive systems that react to events in their environment –Most general approach to embedded, RTS is based on stimulus – response model Stimulus is an event occurring the software system’s environment, that causes a system to react Response is a signal or massage that is sent by the software to its environment Given a stimulus, the system must produce a reaction or response within a specified time. –Periodic stimuli. Stimuli which occur at predictable time intervals For example, a temperature sensor may be polled 10 times per second. –Aperiodic stimuli. Stimuli which occur at unpredictable times For example, a system power failure may trigger an interrupt which must be processed by the system. Stimulus come from the sensor and responses are sent to actuators Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST9

Stimuli and responses for a burglar alarm system StimulusResponse Single sensor positiveInitiate alarm; turn on lights around site of positive sensor. Two or more sensors positiveInitiate alarm; turn on lights around sites of positive sensors; call police with location of suspected break-in. Voltage drop of between 10% and 20% Switch to battery backup; run power supply test. Voltage drop of more than 20%Switch to battery backup; initiate alarm; call police; run power supply test. Power supply failureCall service technician. Sensor failureCall service technician. Console panic button positiveInitiate alarm; turn on lights around console; call police. Clear alarmsSwitch off all active alarms; switch off all lights that have been switched on. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST10 Behavior of the RTS may be defined by listing the stimulus received by the system, the associated responses, and the associated time at which the response must be produced.

A general model of an embedded real-time system Stimulus come from the sensor and responses are sent to actuators. –Separate processes for each type of sensor and actuator Actuators control equipments Actuators may also generate stimuli –For each type of sensors, there may be a sensor management process that handle data collections form sensor, data processing process compute the required response, actuator control process control and manage actuator Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST11

Architectural considerations Because of the need to respond to timing demands made by different stimuli/responses, the system architecture must allow for fast switching between stimulus handlers. –As soon as the stimuli received the control is transferred to correct handler –Timing demands of different stimuli are different so a simple sequential loop is not usually adequate. Real-time systems are therefore usually designed as a set of concurrent, cooperating processes. –A real time Operating system (RTOS) is needed –Functions provided by RTOS is accessed by RTS using real time programming language Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST12

Architectural Pattern Patterns are a means of representing, sharing and reusing knowledge. –An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments. –Patterns should include information about when they are and when are not useful. Patterns may be represented using tabular and graphical descriptions Patterns can be combined in a single system Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST13

Architectural Patterns Architectural Patterns for RTS –Observe and React: used when a set of sensors are routinely monitored and displayed When the sensors show that some event has occurred, system initiate a process to handle that event –Incoming call on cell phone –Environment control: Used when a system include sensors, which provide information about the environment and actuator that can change the environment –In response to the environmental changes detected by the sensor, control signals are sent to the system actuators –Process Pipeline: Used when data has been transformed from one representation to another before it can be processed –Transformation is implemented as a sequence of processing steps can be carried out concurrently Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST14

The Observe and React pattern NameObserve and React DescriptionThe input values of a set of sensors of the same types are collected and analyzed. These values are displayed in some way. If the sensor values indicate that some exceptional condition has arisen, then actions are initiated to draw the operator’s attention to that value and, in certain cases, to take actions in response to the exceptional value. StimuliValues from sensors attached to the system. ResponsesOutputs to display, alarm triggers, signals to reacting systems. ProcessesObserver, Analysis, Display, Alarm, Reactor. Used inMonitoring systems, alarm systems. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST15 Commonly used in monitoring system

Observe and React process structure Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST16

Process structure for a burglar alarm system Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST17

Timing requirements for the burglar alarm system Stimulus/ResponseTiming requirements Power failureThe switch to backup power must be completed within a deadline of 50 ms. Door alarmEach door alarm should be polled twice per second. Window alarmEach window alarm should be polled twice per second. Movement detectorEach movement detector should be polled twice per second. Audible alarmThe audible alarm should be switched on within half a second of an alarm being raised by a sensor. Lights switchThe lights should be switched on within half a second of an alarm being raised by a sensor. CommunicationsThe call to the police should be started within 2 seconds of an alarm being raised by a sensor. Voice synthesizerA synthesized message should be available within 2 seconds of an alarm being raised by a sensor. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST18

Alarm process timing Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST19

The Environmental Control pattern NameEnvironmental Control DescriptionThe system analyzes information from a set of sensors that collect data from the system’s environment. Further information may also be collected on the state of the actuators that are connected to the system. Based on the data from the sensors and actuators, control signals are sent to the actuators that then cause changes to the system’s environment. Information about the sensor values and the state of the actuators may be displayed. StimuliValues from sensors attached to the system and the state of the system actuators. ResponsesControl signals to actuators, display information. ProcessesMonitor, Control, Display, Actuator Driver, Actuator monitor. Used inControl systems. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST20

Environmental Control process structure Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST21

Control system architecture for an anti-skid braking system Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST22

The Process Pipeline pattern NameProcess Pipeline DescriptionA pipeline of processes is set up with data moving in sequence from one end of the pipeline to another. The processes are often linked by synchronized buffers to allow the producer and consumer processes to run at different speeds. The culmination of a pipeline may be display or data storage or the pipeline may terminate in an actuator. StimuliInput values from the environment or some other process ResponsesOutput values to the environment or a shared buffer ProcessesProducer, Buffer, Consumer Used inData acquisition systems, multimedia systems Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST23

Process Pipeline process structure Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST24

Neutron flux data acquisition Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST25

Design Process Activities Order of following activates depends on type of the system, its process and platform requirements Platform selection –Hardware and RTOS is chosen –Factors that influence these choices: Timing constraints on the system, power limitation, the experience of developing team and the price target Stimuli/response identification Timing analysis –For each stimuli and associated responses, identify the time constraints – needed to establish the deadline for the processes of the system Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST26

Design Process Activities Process design –Aggregation of stimulus and response processes into a number of concurrent processes –Architectural pattern may be used to design the process architecture –Optimize the process architectural to reflect the specific requirement Algorithm design –Algo is to be designed for each stimulus and response, to carryout the required computations –Algo may have to be developed earlier in the deign process, to indicate the amount of processing required and time needed to complete the processing Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST27

Design Process Activities Data design –Specify the information that is exchanged by processes and the events that coordinate information exchange –Data structure to be designed to manage the information exchange –Several concurrent processes may share these data structure Process scheduling –Process scheduling is to be designed that will ensure that processes are started in time to meet their deadlines Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST28

Process coordination Processes in a real-time system have to be coordinated and share information. Process coordination mechanisms ensure mutual exclusion to shared resources. –When one process is modifying a shared resource, other processes should not be able to change that resource. Synchronization process is part of most operating systems When designing the information exchange between processes, you have to take into account the fact that these processes may be running at different speeds. –One process is producing and the other process is consuming the information Both producer and consumer process should be running on deadlines- mutual exclusion mechanism Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST29

Process coordination Mutual exclusion –Producer processes collect data and add it to the buffer. –Consumer processes take data from the buffer and make elements available. –Producer and consumer processes must be mutually excluded from accessing the same element. –The buffer must stop producer processes adding information to a full buffer and consumer processes trying to take information from an empty buffer. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST30 Care is needed that producer and consumer process do not access same item at the same time Synchronization primitives (semaphores) are used to ensure synchronization between “PUT” and “GET” operations

Event-driven modeling Real-time systems are often event-driven, with minimal data processing. –For example, a landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial tone. Event-driven modeling shows how a system responds to external and internal events. –It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another. State models are often used to describe real time systems –This assumes that at any time the system is in one of the number of possible states. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST31

State model These model the behaviour of the system in response to external and internal events. –They show the system’s responses to stimuli so are often used for modelling real-time systems. State machine models show system states as nodes (rounded rectangles) and events as arcs (arrows) between these nodes. –When an event occurs, the system moves from one state to another. State charts are an integral part of the UML and are used to represent state machine models. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST32

State diagram of a microwave oven Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 33

States and stimuli for the microwave oven (a) StateDescription WaitingThe oven is waiting for input. The display shows the current time. Half powerThe oven power is set to 300 watts. The display shows ‘Half power’. Full powerThe oven power is set to 600 watts. The display shows ‘Full power’. Set timeThe cooking time is set to the user’s input value. The display shows the cooking time selected and is updated as the time is set. DisabledOven operation is disabled for safety. Interior oven light is on. Display shows ‘Not ready’. EnabledOven operation is enabled. Interior oven light is off. Display shows ‘Ready to cook’. OperationOven in operation. Interior oven light is on. Display shows the timer countdown. On completion of cooking, the buzzer is sounded for five seconds. Oven light is on. Display shows ‘Cooking complete’ while buzzer is sounding. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 34

States and stimuli for the microwave oven (b) StimulusDescription Half powerThe user has pressed the half-power button. Full powerThe user has pressed the full-power button. TimerThe user has pressed one of the timer buttons. NumberThe user has pressed a numeric key. Door openThe oven door switch is not closed. Door closedThe oven door switch is closed. StartThe user has pressed the Start button. CancelThe user has pressed the Cancel button. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 35

Microwave oven operation Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 36

RTOS Standard Operating systems are not being used as execution platform for Real time systems –Most real time systems are built on real time operating systems, and offers the features needed by the system Windows/CE, RTLinux –RTOS manages processes and resource allocation –It starts and stop processes so that stimuli can be handled and allocate memory and process resources Components of RTOS are shown on next slide Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST37

Components of a RTOS Real-time clock –Provides information for process scheduling. Interrupt handler –Manages aperiodic requests for service. Scheduler –Chooses the next process to be run. Resource manager –Allocates memory and processor resources. Dispatcher –Starts process execution. Adv Software Engineering, Asst Prof Athar Mohsin, MSCS 19, MCS-NUST38