Lecture 10 – Concurrent Real-Time Software Task Design
SWE 760Lecture 10 –Concurrent Real-Time Software Task DesignHassan GomaaDept of Computer ScienceGeorge Mason UniversityFairfax, VAReference:H. Gomaa, Chapter 13 - Real-Time Software Design forEmbedded Systems, Cambridge University Press, 2016Copyright 2016 Hassan GomaaAll rights reserved. No part of this document may be reproduced in any form or by any means,without the prior written permission of the author.Copyright 2016 H. GomaaFigure 4.1 COMET/RTE life cycle entalPrototypingSystemTestingCustomerCopyright 2016 Hassan Gomaa2
Software Modeling for RT Embedded Systems1 Develop RT Software Requirements Model– Develop Use Case Model2 Develop RT Software Analysis Model– Develop state machines for state dependent objects– Structure software system into objects– Develop object interaction diagrams for each use case3 Develop RT Software Design Model‒ Design of Software Architecture for RT Embedded Systems‒ Apply RT Software Architectural Design Patterns‒ Design of Component-Based RT Software Architecture‒ Design Concurrent RT Tasks‒ Develop Detailed RT Software Design‒ Analyze Performance of Real-Time Software Designs3Copyright 2016 H. GomaaStructure System into Tasks Concurrent Design with UML Concurrent task structuring criteria– Structure analysis model into concurrent tasks– Task is an active object– Task has thread of control– Consider concurrent nature of system activities– Determine concurrent tasks Define task interfaces Support for concurrent tasks Operating system services: multi-tasking kernelCopyright 2016 H. Gomaa4
Active and Passive Objects Objects may be active or passive Active object– Concurrent Task– Has thread of control Passive object– a.ka. Information Hiding Object– Has no thread of control– Operations of passive object are executedby task– Operations execute in task’s thread ofcontrol Directly or indirectly Software Design terminology– Task refers to active object– Object refers to passive object5Copyright 2016 H. GomaaCopyright 2016 H. Gomaa6
MARTE Modeling and Analysis of Real-Time Embedded systems UML profile– “coherent set of extensions applicable to a givendomain or purpose” (Rumbaugh et al. 2005) Some MARTE stereotypes– Concurrent task: «swSchedulableResource»– Hardware device: «hwDevice»– Timer (hardware or software): «timerResource» MARTE stereotypes can have attributes– E.g., a periodic task with time intervals of 100 msec {isperiodic true, period (100, ms)}7Copyright 2016 H. GomaaExamples of MARTE notationFigure 2.19: Examples of MARTE notation for real-time embedded ableResource»: MicrowaveTimer{isPeriodic true,period (100, ms)}Copyright 2016 H. Gomaa8
Task Structuring Criteria Each task is structured using three orthogonal criteria– Represented using stereotypes MARTE stereotype for concurrent task– «swSchedulableResource» Object role criterion– Carried over from analysis model– E.g., «input » Concurrency criterion– From task structuring– E.g., «event driven»9Copyright 2016 H. GomaaConcurrency Structuring Criteria Define how task is activated– Event driven task Stereotypes:– «event driven» «swSchedulableResource» Activated by external event (e.g., interrupt)– Periodic task Stereotypes:– «timerResource» «swSchedulableResource» Activated by timer– Demand driven task Stereotypes:– «demand» «swSchedulableResource» Activated by arrival of internal messageCopyright 2016 H. Gomaa10
Task Structuring Task Structuring Categories I/O task structuring criteria– How device interface objects are mapped to I/O tasks Internal task structuring criteria– How internal objects are mapped to internal tasks Task priority criteria– Importance of executing task relative to others Task clustering criteria– Whether and how objects should be combined intoconcurrent tasksCopyright 2016 H. GomaaI/O Task Structuring Criteria Event driven I/O task– Task for each event (interrupt) driven I/O device– Event driven device generates interrupt Periodic I/O task– Task for each polled I/O device– I/O device (usually input) sampled at regular intervals Demand driven I/O task– Task for each passive I/O device (usually output)– Computation overlapped with outputCopyright 2016 H. Gomaa12
Characteristics of I/O Devices– Event-driven (interrupt-driven) I/O device– Input device– Generates interrupt when it has produced input– «interruptResource» «input» «hwDevice»– Output device– Generates interrupt when it has finished output– «interruptResource» «output» «hwDevice»– Passive I/O device– Smart deviceCopyright 2016 H. GomaaEvent Driven I/O TaskOne task for each event driven I/O deviceActivated by device I/O interruptReads inputConverts to internal formatDisposes of inputSends message containing dataSignals event (message with no data)Writes to data storeCopyright 2016 H. Gomaa14
Figure 13.1 Example of an event driven input taskFigure 13.1a Analysis model – communication diagram1: Arrival Event«input»«hwDevice»: ArrivalSensor«input»: ArrivalSensorInput2: Train Arrival:TrainControlHardware / software boundaryFigure 13.1b Design model – concurrent communication diagram«interruptResource»«input»«hwDevice»: ArrivalSensor1: arrivalInterrupt(arrivalData)«event driven»«input»«swSchedulableResource»: ArrivalSensorInput2: trainArrivalHardware / software boundaryCopyright 2016 H. Gomaa«swSchedulableResource»: TrainControl15Event Driven Input Task- PseudocodeInitialize external device;loop-- Wait for external interrupt from input devicewait (externalEvent);Read input from device;if input is recognizedthenConvert input to internal format;-- send message to consumer task or write to passive entity object;send (message, consumer);else – input was not recognized;-- handle error, e.g., output or send error message;end if;end loop;Copyright 2016 H. Gomaa16
Characteristics of I/O Devices–Passive I/O device– Device does not generate interrupt– Input from passive device– « passive » «input» «hwDevice»– Polled on periodic basis– Output to passive device– « passive » «output» «hwDevice»– On demandCopyright 2016 H. GomaaPeriodic I/O TaskTask for each polled I/O deviceActivation of task is periodicSamples I/O devicePeriodic I/O taskActivated by timer eventPerforms I/O operationWaits for next timer eventCopyright 2016 H. Gomaa18
Figure 13.2 Example of a periodic input taskFigure 13.2a Analysis model – communication diagram1: PressureData«input»«hwDevice»: PressureSensor«input»: PressureSensorInput2: CurrentPressure«entity»: PressureDataHardware / software boundaryFigure 13.2b Design model – concurrent communication diagram0: timerEvent«timerResource»«hwDevice»: DigitalTimer1: read(out pressureData)«passive»«input»«hwDevice»: PressureSensorCopyright 2016 H. urce»: PressureSensorInput2: update(in currentPressure)Hardware / software boundary«entity»: PressureData19Periodic Input task- PseudocodeInitialize external device;loop-- Wait for timer event from external clock-- External clock could be RT clock or operating system timer;wait (timerEvent);Read current value of input from device;if input is recognizedthenConvert input to internal format;--optionally if device is digital device.if value of input NOT EQUAL previous value-- send message to consumer task or write to passive entity object;then send (message, consumer);else – input was not recognized;-- handle error, e.g., output or send error message;end if;end loop;Copyright 2016 H. Gomaa20
Demand Driven I/O Task Task for each passive I/O device (usually output)– Passive I/O device does not need to be polled– Computation overlapped with output Task output to device overlapped with Computational task that produces data Usually for passive output device– Demand driven I/O task Passive input devices more likely to be polled– Periodic input task21Copyright 2016 H. GomaaFigure 13.3 Example of a demand output taskFigure 13.3a Analysis model – communication diagram«algorithm»: SpeedComputationAlgorithm1: Speed Value«output»: SpeedDisplayOutput2: Visual SpeedData«output»«hwDevice»: DisplayHardware / software boundaryFigure 13.3b Design model – concurrent communication rce»:SpeedComputationAlgorithm1: rce»: SpeedDisplayOutput2: visualSpeedDataHardware / software boundaryCopyright 2016 H. Gomaa«passive»«output»«hwDevice»: Display22
Demand Driven Output Task- PseudocodebeginInitialize output device, if needed;loop-- Wait for message from producer task arriving via connector;aConnector.receive (message);Extract message name and any message parameters from message;-- Process message;Convert data to output format if needed,Output data to output device;if output device error;Handle error case;end if;end loop;end;23Copyright 2016 H. GomaaEvent Driven Proxy Task Interfaces to computer-based system– External system– Smart device Microprocessor driven I/O device Connected to embedded system using communication link Communicates with embedded system using messages– Uses communication protocol, e.g., TCP/IPCopyright 2016 H. Gomaa24
25Copyright 2016 H. GomaaInternal Task Structuring Criteria Periodic task– Task for each periodic activity Demand task– Task for each demand driven internal activity Control task– Task executes state machine User interaction task– Task for each sequential user activityCopyright 2016 H. Gomaa26
Periodic TaskTask for each periodic activityTask activated periodicallyActivated by timer eventPerforms activityWaits for next timer event27Copyright 2016 H. GomaaFigure 13.6 Example of periodic taskFigure 13.6a Analysis model – communication diagram1: Timer Event«external timer»: DigitalTimer«timer»: MicrowaveTimer3: TimerExpired: MicrowaveControl2: decrementTime(out timeLeft)«entity»: OvenDataFigure 13.6b Design model – concurrent communication diagram1: timerEvent«timerResource»«hwDevice»: ce»: MicrowaveTimer{isPeriodic true,period (1, sec)}3: timerExpired«swSchedulableResource»: MicrowaveControl2: decrementTime(out timeLeft)«entity»: OvenDataCopyright 2016 H. Gomaa28
Periodic Algorithm Task- Pseudocodebeginloop-- Wait for timer event;wait (timerEvent);execute periodic algorithm;prepare output message containingmessage name and parameters-- send output message;aConnector.send (message);end if;end loop;end;29Copyright 2016 H. GomaaDemand Driven TaskActivity executed on demandActivated by internal event or messageMap to Demand TaskDemand taskActivated on demand by event or message sent bydifferent taskPerforms demanded actionWaits for next event or messageCopyright 2016 H. Gomaa30
Example of Demand Driven Task-Analysis Model31Copyright 2016 H. GomaaExample of demand driven taskCopyright 2016 H. Gomaa32
Demand Driven Task- Pseudocodebeginloop-- Wait for message or event from producer task arriving via message connector;aConnector.receive (message);Extract message name and any message parameters from message;Perform requested action on demand- Read data from passive entity object(s) if needed- Execute action- Update data in passive entity object(s) if neededPrepare output message or response containing message name and parameters-- send output message or event;aConnector.send (message);end loop;end;33Copyright 2016 H. GomaaState Dependent Control TaskTask executes statechartState dependent control object executes statechartExecution of statechart is sequentialOne task for each control objectCan have multiple tasks of same typeCopyright 2016 H. Gomaa34
Figure 13.8 Example of state dependent control taskFigure 13.8a Analysis model – communication diagram1: Train Arrival«input»:ArrivalSensorInput«state dependentcontrol»: TrainControl2: DecelerateCommand«algorithm»: SpeedAdjustmentFigure 13.8b Design model – concurrent communication diagram«event SensorInput1: trainArrival«demand»«state dependent control»«swSchedulableResource»:TrainControl2: lableResource»:SpeedAdjustment35Copyright 2016 H. GomaaloopState DependentControl Task- Pseudocode-- Messages from all senders are received on Message QueueReceive (messageQ, message);-- Extract the event name and any message parametersnewEvent message.event-- Assume state machine is encapsulated in object aSTM;-- Given the incoming event, lookup state transition table;-- change state if required; return action to be performed;aSTM.processEvent (in newEvent, out action);-- Execute state dependent action(s) as given on state machine;case state dependent action ofaction 1:execute state dependent action 1;exit;action 2execute state dependent action 1;exit;.action nexecute state dependent action n;exit;end case;end loop;Copyright 2016 H. Gomaa36
Coordinator Task Decision making task– Not state dependent– Action depends on input received– Decides when, and in what order, other actions execute– Encapsulates decision making logic– To execute action Sends message to another task to execute action Calls operation of passive object to execute action37Copyright 2016 H. GomaaExample of Coordinator TaskCopyright 2016 H. Gomaa38
Coordinator Task- Pseudocodeloop-- Messages from all senders are received on Message QueueReceive (messageQ, message);Extract message name and message parameters from message;-- For coordinator task, action is not state dependent;case message ofaction 1:execute action 1;exit;action 2execute action 2;exit;.action nexecute action n;exit;end case;end loop;39Copyright 2016 H. GomaaUser Interaction TaskOne task for each sequential user activityMulti-user systemOne task per userUser may also spawn background tasksWindowing systemUser engaged in multiple activitiesEach window executes sequential activityOne task for each windowCopyright 2016 H. Gomaa40
Figure 18.12 Example of user interaction taskFigure 13.11 Example of event driven user interaction task and demand driven service taskFigure 13.11a Analysis model – communication diagram1: OperatorCommand3: Display«user interaction»: OperatorInteraction2: SensorRequest«service»: SensorDataService2.1: Sensor Data: Operator DataFigure 13.11b Design model – concurrent communication diagram1: operatorCommand: Operator«event driven»«user ce»:SensorDataService2: read(out sensorData)3: displayData41Copyright 2016 H. GomaaFigure 18.12 Example of user interaction taskFigure 13.11 Example of event driven user interaction tasks and demand driven service taskFigure 13.11c Design model – concurrent communication diagram1: factoryStatusQuery«event driven»«user usWindow2: edulableResource»:FactoryStatusService3: statusDisplayData1A: alarmQuery: Operator3A: alarmDisplayDataCopyright 2016 H. Gomaa«event driven»«user mWindow2A: ulableResource»:FactoryAlarmService42
beginloopUser Interaction Task- PseudocodeOutput menu or prompt to userWait (user response)Read user inputProcess user input and have further interactions with user if necessary.-- Send message with user request to consumer taskaConnector.send (user request);-- Wait for response from consumer task arriving via message connector;aConnector.receive (consumer response);Extract and process consumer response;Prepare textual and/or graphical output for user;Output response to userend loop;end;43Copyright 2016 H. GomaaTask Priority Criteria Important consideration– Performance Analysis– Real-Time Scheduling Rate Monotonic Analysis Time critical– Activity that has hard deadline– Map to time critical task– E.g., high priority event driven input task Arrival Sensor Input task (Fig. 13.1) Non-time-critical computationally intensive– Low priority activity– E.g., low priority computationally intensive task Speed Computation Algorithm task (Fig. 13.3)Copyright 2016 H. Gomaa
Task Clustering Criteria Temporal clustering– Activities activated by same event Sequential clustering– Activities must be executed sequentially Control clustering– Control object grouped with objects it activates Task Inversion– Map all objects of same type to one taskCopyright 2016 H. GomaaTemporal Clustering Candidate tasks– Tasks determined during first stage of Task Structuring Two or more candidate tasks– Each candidate task executes an activity– Candidate tasks activated by same event, e.g. timer– No sequential dependency between tasks Candidate tasks grouped into one task Best form of temporal clustering– Candidate tasks are functionally related– Have same sampling rates Weaker form of temporal clustering– Sampling rates are multiples of one anotherCopyright 2016 H. Gomaa
Copyright 2016 H. GomaaFigure 13.12b Example of temporal clustering- After temporal clustering«timerResource»«hwDevice»: DigitalClock«passive»«input»«hwDevice»: TemperatureSensor«passive»«input»«hwDevice»: PressureSensorCopyright 2016 H. Gomaa2: read (outtempData)1: timerEvent«timerResource»«temporal r4: read (outpressureData){isPeriodic true,period (100, ms)}3: update(in currentTemp)5: update(in �«sharedMutualExclusionResource»: SensorDataRepository
Sequential Clustering Candidate tasks– Tasks determined during first stage of Task Structuring Two or more candidate tasks– Each candidate task executes an activity– Candidate tasks must execute in predefined sequence– First candidate task in sequence activated by event– Subsequent candidate tasks should execute withoutdelay Candidate tasks grouped into one taskCopyright 2016 H. GomaaFigure 13.13 Example of Sequential Clusteringa) Before sequential clusteringb) After sequential clustering«timerResource»«hwDevice»: DigitalTimer«timerResource»«hwDevice»: DigitalTimertimerEventtimerEventread (out location,out destination)«entity»: rce»: utput»«swSchedulableResource»: StatusDisplayOutputvehicleStatusCopyright 2016 H. Gomaaread (out location,out destination)«passive»«output»«hwDevice»: Display«entity»: VehicleStatus«timerResource»«sequential clustering»«swSchedulableResource»: tput»«hwDevice»: Display50
Control ClusteringState dependent control object grouped with actions or activitiesState dependentAction triggered by control objectExecutes at state transition - CombineActivity enabled/disabled by control objectExecutes for duration of state - Do not combineActivity triggered by control objectExecutes for duration of state - Possibly combineNon-state dependent actionsSend events to control object- PossiblycombineCopyright 2016 H. GomaaFigure 13.14 Example of Control Clusteringa) Before control clustering«demand»«state dependent control»«swSchedulableResource»:Pump passive»«output»«hwDevice»:PumpEngineHardware / software boundaryb) After control clustering«demand»«control clustering»«swSchedulableResource»:Pump ce»:PumpEngineHardware / software boundaryCopyright 2016 H. Gomaa52
Multiple Instance Task InversionMultiple tasks of same typeUsed to model multiple objects of same typePotential ProblemHigh overhead of modeling each object using separatetaskTask inversionModel all objects of same type using one taskUse separate data record for each object to
George Mason University Fairfax, VA Reference: H. Gomaa, Chapter 13 - Real-Time Software Design for . 1 Develop RT Software Requirements Model – Develop Use Case Model 2 Develop RT Software Analysis Model – Develop state machines for state dependent objects
Introduction of Chemical Reaction Engineering Introduction about Chemical Engineering 0:31:15 0:31:09. Lecture 14 Lecture 15 Lecture 16 Lecture 17 Lecture 18 Lecture 19 Lecture 20 Lecture 21 Lecture 22 Lecture 23 Lecture 24 Lecture 25 Lecture 26 Lecture 27 Lecture 28 Lecture
Concurrent coding features Concurrent Coding Dashboard is the launch padfor concurrent coders: Manage workflow Complete final coding Concurrent Coding Worklists Can be defined like CDI worklists Priority factors that support concurrent coding workflow ocase status, priority score, last coder, last reviewer Ability to add findings .
Lecture 1: A Beginner's Guide Lecture 2: Introduction to Programming Lecture 3: Introduction to C, structure of C programming Lecture 4: Elements of C Lecture 5: Variables, Statements, Expressions Lecture 6: Input-Output in C Lecture 7: Formatted Input-Output Lecture 8: Operators Lecture 9: Operators continued
Modeling, Simulation, and Design of Concurrent Real-Time Embedded Systems Using Ptolemy Edward A. Lee Robert S. Pepper Distinguished Professor EECS Department UC Berkeley Ptutorial EECS 249, Sept. 13, 2012 Lee, Berkeley 2 The Ptolemy Project The Ptolemy project studies modeling, simulation, and design of concurrent, real-time, embedded systems.
Lecture 1: Introduction and Orientation. Lecture 2: Overview of Electronic Materials . Lecture 3: Free electron Fermi gas . Lecture 4: Energy bands . Lecture 5: Carrier Concentration in Semiconductors . Lecture 6: Shallow dopants and Deep -level traps . Lecture 7: Silicon Materials . Lecture 8: Oxidation. Lecture
TOEFL Listening Lecture 35 184 TOEFL Listening Lecture 36 189 TOEFL Listening Lecture 37 194 TOEFL Listening Lecture 38 199 TOEFL Listening Lecture 39 204 TOEFL Listening Lecture 40 209 TOEFL Listening Lecture 41 214 TOEFL Listening Lecture 42 219 TOEFL Listening Lecture 43 225 COPYRIGHT 2016
Partial Di erential Equations MSO-203-B T. Muthukumar tmk@iitk.ac.in November 14, 2019 T. Muthukumar tmk@iitk.ac.in Partial Di erential EquationsMSO-203-B November 14, 2019 1/193 1 First Week Lecture One Lecture Two Lecture Three Lecture Four 2 Second Week Lecture Five Lecture Six 3 Third Week Lecture Seven Lecture Eight 4 Fourth Week Lecture .
1.1 Hard Real Time vs. Soft Real Time Hard real time systems and soft real time systems are both used in industry for different tasks [15]. The primary difference between hard real time systems and soft real time systems is that their consequences of missing a deadline dif-fer from each other. For instance, performance (e.g. stability) of a hard real time system such as an avionic control .
