Calibration of Deployment Simulation Models - A Multi-Paradigm Modelling Approach
-
Upload
dgianni -
Category
Technology
-
view
298 -
download
2
description
Transcript of Calibration of Deployment Simulation Models - A Multi-Paradigm Modelling Approach
Karel de Grote-Hogeschool TERA-Labs www.kdg.be
Universiteit Antwerpen ANSYMO
www.ua.ac.be
Calibration of Deployment Simulation Models
A Multi-Paradigm Modelling Approach
Joachim Denil Hans Vangheluwe
Paul De Meulenaere Serge Demeyer
www.teralabs.org
http://Ansymo.ua.ac.be
Introduction
• Problem Statement – MDE has advantages – Simulation is used often
• For example: early deployment space exploration
2
www.teralabs.org
http://Ansymo.ua.ac.be
Examples
3
An Integrated SystemC Framework for Real-Time Scheduling Assessments on System Level Prih Hastono, Stephan Klaus and Sorin A. Huss
Integrated Circuits and Systems Laboratory Department of Computer Science - Technische Universität Darmstadt
Hochschulstr. 10, 64289 Darmstadt Germany {hastono|klaus|huss}@iss.tu-darmstadt.de
Abstract
The rate and reactivity figures of embedded systems are distinctly influenced by the chosen scheduling policy since embedded software processes more and more dominate the functionality of embedded systems. Seeking a suitable schedule policy typically requires some heuristics in conjunction with analytic approaches. A stand-alone scheduling simulator can considerably help reducing these efforts. However, a tedious integration work will be required in order to jointly validate both behavioural and architectural design decisions. Therefore, we present an open framework for real-time scheduling simulation by exploiting the SystemC modeling style. Especially the real-time software modeling capabilities of SystemC are enhanced to a large extent by this work, which allows an integration of software tasks scheduling simulation into existing approaches of modeling using SystemC. Thus, design alternatives, scheduling decisions, and associated real-time performance can be explored in early design phases.
1. Introduction One important issue of a successful design methodology
for complex real-time embedded systems is a realistic, reliable, and fast system-level simulation support. Design and implementation alternatives should be validated as early as possible in the design flow in order to allow for a comprehensive design space exploration. Especially software execution properties must be timely taken into account, since software modules more and more dominate the functionality of embedded systems. The execution of software in such real-time systems is in general controlled by a real-time operating system (RTOS). In order to achieve real-time performance, the system behavior predictability is of paramount concern. Central to the method of achieving this predictability is the scheduling algorithm that decides which activity is allowed to execute at some instant of time, so that a maximum amount of tasks meet their deadlines reliably. An optimal schedule may be found analytically during schedulability analysis. However, it is often desirable to verify its results or to open the possibility to find new approaches empirically during scheduling exploration. Thus, the need of a flexible customizable scheduling simulator is advocated for assessing the behavior of a certain scheduling approach expressed as an algorithm under simulated conditions. Such a scheduling simulator must provide enough services to let the real-time researcher stay focused on the details of the scheduling algorithm and yet must be open and flexible enough to support new solution strategies. In this paper we take into consideration that the system is being modeled in SystemC [2] thus providing a simulation model of the system under development in the framework which is based on SystemC, too. The choice for working with a system level design language is important for ensuring model portability. We select SystemC because it emerges as the industrial standard for both transaction-level modeling and system-level design language for co-simulation of mixed HW/SW systems. In the framework scheduling simulation has to be done in the same environment of both for the functional system-level validation and the design
space exploration. Such a framework for scheduling simulation is illustrated in Figure 1. Based on analysis and selection operations during simulation a scheduling decision can be taken. The scenario of interfacing both the system and scheduling simulation is illustrated in Figure 2. It presents a typical viewpoint for the interface for real-time scheduling simulation, which may easily be modified for real-time scheduling assessment. In this scenario, the system status updates the initial conditions when a decision is needed - either based on an exception or continuously. If alternatives exist, then each of them would be simulated and the best may then be selected. Thus, the proposed framework is a novel solution to the problem of integrating both system model and scheduling simulation. A SystemC model that represents real-time systems composed from hardware-software and their interactions thus can be evaluated under various scheduling policies.
2. Related Work Scheduling for embedded systems performance estimation
and synthesis has been intensively studied in the last years [4]. Different approaches for scheduling simulation of real-time systems focused on a particular scheduling problems can be found, such as in PERTS [5] and STRESS [6]. A review of recent developments using simulation as a tool in real-time scheduling can be found in [1]. SystemC, the increasingly used C++ based modeling language for system level design, is intensively exercised by its community. As modeling and simulation language, it requires extension to cope with software modeling features including a capability to model real-time software. However, in the current version of SystemC (2.0), this feature is still missing [3]. Therefore, we propose in this paper the scheduling simulation capability extension to work on SystemC models aiming to extend of its usage for real-time scheduling assessment. The basic approach of [7] is mapped to SystemC by extending the scope considerably to allow for a complete integration of HW/SW scheduling simulation into the embedded system co-design flow.
3. Simulation Framework Overview sy s tem lev el
Sy stem C m odel
s che du ling s im u lation e ng ine
o n-line se ction
u se r sche d ule a s A dd -In
G U I
errorin jec t ion
algorith m for error in jec t ion
s tat ic a lgorithm
dy nam icalgorithm
log f iles
c om ula t if s torage
logging and pres entat ion
ev ents and data recept ion
o ff-l in e s e ction
res ult analys is
HW Model
Figure 1. Proposed Simulation Framework
The proposed simulation framework integrates functional validation with architectural and scheduling exploration on system level. The simulation engine along with software code
processes. In this technique, the definition of the new schedule object is done by class derivation form the sim_schedule class provided by the framework. The scheduling algorithm is implemented by overloading the predefined methods. Because the scheduling policy can be either static or dynamic, the class provides two methods to override, i.e., offline_policy()and online_policy(). The methods overriding is illustrated in Figure 8. class user_sim_engine : public sim_engine { public: user_sim_engine_os(sc_module_name name) : sim_engine (name) { on_static_schedule = rma_schedule; on_line_schedule = rma_schedule; } void rma_schedule (vector<rt_task*> &tasks) { /* The definition of function “RMA_schedule” is here.*/ } void rma_schedule (vector<rt_task*> &tasks, sc_time &t) { /* The definition of function “EDF_schedule” is here*/ } };
Figure 7. Re-scheduling by Callback Overriding
class user_schedule : public sim_schedule { public: user_schedule(sc_module_name aname) : sim_schedule(aname){} void offline_policy(vector<rt_task*> &tasks) { /* Algorithm of user static scheduling policy is defined here. E.g. RMA */ } void online_policy(vector<rt_task*> &tasks,sc_time %t) { /* Algorithm of user online scheduling policy is defined here. E.g. EDF */ } };
Figure 8. Re-scheduling by Port Binding
5. Design Flow to Experiment Results This section demonstrates the feasibility of the proposed
methods for embedded systems design by means of an application example. As an example we exploit an autonomous robot equipped with ultrasound distance sensors, a camera, and a wireless data link subsystem, where its entire specification consisting of 17 tasks is captured os a task graph along with their timings properties (estimated max-min execution times). The design flow starts with the allocated specification model. During system design, the functional specification is then partitioned onto multiple processing elements (PEs). In this example, the envisaged generic hardware architecture for the information processing of this robot is a multi-processor system composed from a set of Pes, i.e., a co-processor on a PCI FPGA board, a PC, and a microcontroller attached to the mobile robot. The PEs communicate through a PCI bus (between PC and FPGA) and via a set of wireless RS232 modems (between PC on mobile robot and PC). Due to the inherently sequential nature of one PE, tasks mapped to the same PE need to be serialized and then scheduled statically or dynamically. In case of a dynamic scheduling implementation, a scheduler is required, where in the proposed framework is a customizable component of scheduling simulator module.
Next, the process of generating SystemC models of the distributed information processing of the robot is based on the partitioned model of the specification. This generated model forms the basis for the evaluation of the system-level design decisions exploiting the proposed simulation environment. The PEs are modeled by SystemC models that communicate to each other by means of SystemC channels. In order to allow for scheduling with the proposed simulator, the tasks running on each PE are converted into simulator-based tasks created by instantiation from the sim_task class (See Figure 6). By invoking the simulator service for task execution timing (wait()method), the tasks execution times are modeled statistically based on the Gumbel distribution [8]. The resulting model is a SystemC model consisting from multiple PEs modules (PC, PC, FPGA), which communicate via a set of SystemC channels (RS232, PCI Bus). A PE in which more than
one tasks are executed schedules the tasks based on scheduling algorithm implemented on the simulator object instantiated internally in the PE modules (from sim_basic_engine class). In this case the simulator object acts like an RTOS. A scheduling algorithm is implemented on a simulator object by creating the instances from user_custimized_schedule class and overloading its predefined methods provided for scheduling algorithm insertion. Finally, the SystemC simulation is running and relevant simulation data is recorded.
Due to the stochastic execution times one hundred different runs were executed and evaluated. The evaluation results regarding task execution times for different scheduling policies are presented in Table 1. In our case, we get a deviation value of about 3% of system ACET on simulation with 10% task ACET deviation selected for each individual task used to generate task execution time. Based on this result a suited scheduling strategy can be chosen. The different scheduling policies are to the simulator by linked callback mechanism, which takes a few seconds and a recompilation. The scheduling co-simulation within the proposed framework takes only 5 seconds for this example on an AMD Athlon™ 1600 processor. Due to the structure of the problem, dynamic or preemptive scheduling does not lead to better results. So, since this robot is not a highly safe-critical application, event driven scheduling is considered as the most feasible strategy in this case. One comes up to this result from high-level analysis of this embedded information system.
Table 1. Simulation Performance Results BCET ACET WCET
Time triggered 540 ms 540 ms 540 ms Event Driven 331 ms 357 ms 431 ms Priority-based Ordering 335 ms 361 ms 435 ms Preemptive Scheduling 335 ms 361 ms 435 ms
6. Conclusions and Future Work In this paper, a SystemC based scheduling simulator along
with its integrated environment is presented. It provides a framework for assessing scheduling algorithms options, while the bulk of the design is modeled in SystemC at a high abstraction level. It is thus possible to exercise both hardware and real-time software modules of system-level allowing early system performance assessment as well as verification and validation of different implementation alternatives and scheduling strategies. Application scenarios for modeling distributed system is a challenging subject for future work in order to extend the simulation methodology for global scheduling analysis.
7. References [1] C. M. Harmonosky, Simulation-Based Real-Time Scheduling:
Review of Recent Developments, In Proc. of the 1995 Winter Simulation Conference, December 1995.
[2] SystemC, http://www.systemc.org. [3] T. Grötker, Modeling Software with SystemC 3.0, Synopsys Inc,
6th European SystemC Users Group Presentations, 2002. [4] F. Balarin, et. al., Scheduling for Embedded Real-Time Systems.
IEEE Design & Test of Computers, January 1998. [5] J. W. S. Liu, et. al., PERTS: A prototyping environment for real-
time systems, In: Proc. of 14th Real-Time Systems Symposium, IEEE, December 1993.
[6] N.C. Audsley, et. al., STRESS: A simulator for hard real-time systems. Software Practice and Experience, July 1994.
[7] T. Kramp, M. Adrian, R. Koster, An open Framework for Real-time Scheduling Simulation, IPDPS Workshops, 2000.
[8] S. M. Petters, How much Worst Case is Needed in WCET Estimation?, In 2nd International Workshop on Worst Case Execution Time Analysis, Vienna, Austria, June 2002.
P. Hastono, S. Klaus, and S. A. Huss; An integrated SystemC framework for real-time scheduling assessments on system level; in Proceedings of IEEE Int. Real-Time Systems Symposium, 2004.
www.teralabs.org
http://Ansymo.ua.ac.be
Examples
4
S. Becker, H. Koziolek, and R. Reussner; The Palladio component model for model-driven performance prediction,� Journal of Systems and Software, vol. 82, no. 1, pp. 3-22, Jan. 2009.
www.teralabs.org
http://Ansymo.ua.ac.be
Examples
5
J. Denil, H. Vangheluwe, P. Ramaekers, P. De Meulenaere, and S. Demeyer; DEVS for AUTOSAR platform modelling; in Proceedings of the 2011 SpringSim Multi-Conference: DEVS/TMS, 2011.
www.teralabs.org
http://Ansymo.ua.ac.be
Introduction
• Problem Statement – MDE has advantages – Simulation is used often – PROBLEM: Calibration of simulation
models • Solution:
– Use MDE techniques (generative) to calibrate models
6
www.teralabs.org
http://Ansymo.ua.ac.be
Calibration?
• Estimate model parameters to reflect reality
• For example: – Physical model: Gain of a motor – Queuing system: Distribution of arrival
times – In Previous examples:
• WCET • Distribution of Execution Times
7
www.teralabs.org
http://Ansymo.ua.ac.be
Calibration?
• State of Art: – Instrument Source Code – Make test programs (trace driven) – Execute on Target or Cycle-true
Simulator • Cyber-Physical Systems:
– Input not only from environment but also from feedback!
8
www.teralabs.org
http://Ansymo.ua.ac.be
Motivating Example
9
www.teralabs.org
http://Ansymo.ua.ac.be
MPM Design of the Power Window
UP
DOWN
UP
DOWN
Controller
ForceDetect
PsgrButtons
DriverButtons
DrvChildLock
DrvIgnition
ObjectInWindow
ToMotor
10.00.0
0.0 100.0
50.0
0.0
0.0
X
X+ +
+
<
>
=
AngularVelocity
windowPos
CAtTop
CInitAngularVelocity CInitPositionWindow
AngularVelocity
joinedUpDown
motorSignal
friction
motorSignal
FAV
MotorGain
invFriction
motorSignal
Cfriction
m
CAtBottom
goingUp
goingDown
windowPos
noObject
<
>
windowPos
+AtBottom
AtTop
+FeedBack
TopOrBottom
ObjectDetected
1.0
0.0
ObjectIn
SWC
Logic
SWC
Control_Passenger
SWC
Control_Driver
SWC
Sensor_Load
SWC
DC_Motor
PsgrButton
Multi-Paradigm Modelling (MPM): “Model Everything
at the right level(s) of abstraction, using (an) appropriate formalism(s)”
10
www.teralabs.org
http://Ansymo.ua.ac.be
Problem Revisited
11
SWC
Logic
SWC
Control_Passenger
SWC
Control_Driver
SWC
Sensor_Load
SWC
DC_Motor
DrvDoor
MPC5567
BodyLogic
MPC5567
PsgDoor
MPC5567
Body
CAN
Deploy
Performance Characteristics
www.teralabs.org
http://Ansymo.ua.ac.be
Architecture
• Use target hardware for SW • Use host for simulation
12
Input Values and Triggers
Host Target Platform
Output Values and Traces
www.teralabs.org
http://Ansymo.ua.ac.be
Generating Infrastructure
13
www.teralabs.org
http://Ansymo.ua.ac.be 14
www.teralabs.org
http://Ansymo.ua.ac.be
Generating Infrastructure
15
www.teralabs.org
http://Ansymo.ua.ac.be 16
www.teralabs.org
http://Ansymo.ua.ac.be
Generating Infrastructure
17
www.teralabs.org
http://Ansymo.ua.ac.be 18
www.teralabs.org
http://Ansymo.ua.ac.be
Generating Infrastructure
19
www.teralabs.org
http://Ansymo.ua.ac.be
Combining Models
20
10.00.0
0.0 100.0
50.0
0.0
0.0
X
X+ +
+
<
>
=
SWC
Logic
SWC
Control_Passenger
SWC
Control_Driver
SWC
DC_Motor
SWC
Sensor_Load
AngularVelocity
windowPos
AtTop
CInitAngularVelocity
DrvButton
CInitPositionWindow
AngularVelocity
joinedUpDown
motorSignal
friction
motorSignalobject
FAV
MotorGain
ObjectIn
invFriction
motorSignal
Cfriction
m
PsgrButton
AtBottom
DrvIgnition
goingUp
goingDown
windowPos
noObject
DrvChildLock
<
>
windowPos
+
AtBottom
AtTop
+FeedBack
TopOrBottom
ObjectDetected
1.0
0.0
www.teralabs.org
http://Ansymo.ua.ac.be
Generating Infrastructure
21
www.teralabs.org
http://Ansymo.ua.ac.be 22
10.00.0
0.0 100.0
50.0
0.0
0.0
X
X+ +
+
<
>
=
SWC
Logic
SWC
Control_Passenger
SWC
Control_Driver
SWC
DC_Motor
SWC
Sensor_Load
AngularVelocity
windowPos
AtTop
CInitAngularVelocity
DrvButton
CInitPositionWindow
AngularVelocity
joinedUpDown
motorSignal
friction
motorSignalobject
FAV
MotorGain
ObjectIn
invFriction
motorSignal
Cfriction
m
PsgrButton
AtBottom
DrvIgnition
goingUp
goingDown
windowPos
noObject
DrvChildLock
<
>
windowPos
+
AtBottom
AtTop
+FeedBack
TopOrBottom
ObjectDetected
1.0
0.0
Input Values and Triggers
Host Target Platform
Output Values and Traces
www.teralabs.org
http://Ansymo.ua.ac.be 23
www.teralabs.org
http://Ansymo.ua.ac.be
Generating Infrastructure
24
www.teralabs.org
http://Ansymo.ua.ac.be
Results
25
10.00.0
0.0 100.0
50.0
0.0
0.0
X
X+ +
+
<
>
=
SWC
Logic
SWC
Control_Passenger
SWC
Control_Driver
SWC
DC_Motor
SWC
Sensor_Load
AngularVelocity
windowPos
AtTop
CInitAngularVelocity
DrvButton
CInitPositionWindow
AngularVelocity
joinedUpDown
motorSignal
friction
motorSignalobject
FAV
MotorGain
ObjectIn
invFriction
motorSignal
Cfriction
m
PsgrButton
AtBottom
DrvIgnition
goingUp
goingDown
windowPos
noObject
DrvChildLock
<
>
windowPos
+
AtBottom
AtTop
+FeedBack
TopOrBottom
ObjectDetected
1.0
0.0
Figure 7. The combined model using generic links to connect entities in the different formalisms.
our generated infrastructure match the values obtained by thehardware instrumentation.
Execution Time (µs) Childlock Off ChildLock On20.375 12500 1200019.875 2500 3000
Table 1. Results for the Control Driver runnable.
Execution Time (µs) Childlock Off ChildLock On11.375 9000 1000010.875 6000 5000
Table 2. Results for the Control Passenger.
Execution Time (µs) Childlock Off ChildLock On7.625 15000 15000
Table 3. Results for the Sensor Load runnable.
The obtained values from the different runnables can beused as input parameters for the system performance simula-tion models.
6. DISCUSSIONOn the tooling side of this approach a problem can occur
in combining the different models. Not every tool is able tocombine different meta-models as this is prerequisite to auto-matically devising the interface code. A possible solution tothis problem is to create a super-meta-model which containsthe elements of the different formalisms[11].
Execution Time (µs) Childlock Off ChildLock On20.000 7500 499920.500 0 1000120.875 7499 021.375 1 0
Table 4. Results for the Logic runnable. The strange resultof the last row is because of a special condition that can onlyoccur in the first execution round.
Execution Time (µs) Childlock Off ChildLock On8.00 6000 30008.250 9000 12000
Table 5. Results for the DC Motor runnable.
In the paper we focused on the calibration of a single ap-plication to be deployed on a single hardware platform type.In real situations multiple types of platforms can be usedwhen deploying such distributed applications. During the de-ployment space exploration the choice of platforms is made.When mixing multiple platforms during deployment multiplecalibration steps are necessary. A calibration for another plat-form can be done by using another “middleware template”,used in Section 4 to generate the platform and interface code,that contains the low-level code to transmit and receive mes-sages over the serial bus and do the measurement of the ex-ecution time. The other transformations remain unchanged.This applies as well for other applications. All transforma-tions are generic and can be used for all applications basedon this workflow.
SWC
Logic
SWC
Control_Passenger
SWC
Control_Driver
SWC
Sensor_Load
SWC
DC_Motor
DrvDoor
MPC5567
BodyLogic
MPC5567
PsgDoor
MPC5567
Body
CAN
10.00.0
0.0 100.0
50.0
0.0
0.0
X
X+ +
+
<
>
=
SWC
Logic
SWC
Control_Passenger
SWC
Control_Driver
SWC
DC_Motor
SWC
Sensor_Load
AngularVelocity
windowPos
AtTop
CInitAngularVelocity
DrvButton
CInitPositionWindow
AngularVelocity
joinedUpDown
motorSignal
friction
motorSignalobject
FAV
MotorGain
ObjectIn
invFriction
motorSignal
Cfriction
m
PsgrButton
AtBottom
DrvIgnition
goingUp
goingDown
windowPos
noObject
DrvChildLock
<
>
windowPos
+
AtBottom
AtTop
+FeedBack
TopOrBottom
ObjectDetected
1.0
0.0
Figure 7. The combined model using generic links to connect entities in the different formalisms.
our generated infrastructure match the values obtained by thehardware instrumentation.
Execution Time (µs) Childlock Off ChildLock On20.375 12500 1200019.875 2500 3000
Table 1. Results for the Control Driver runnable.
Execution Time (µs) Childlock Off ChildLock On11.375 9000 1000010.875 6000 5000
Table 2. Results for the Control Passenger.
Execution Time (µs) Childlock Off ChildLock On7.625 15000 15000
Table 3. Results for the Sensor Load runnable.
The obtained values from the different runnables can beused as input parameters for the system performance simula-tion models.
6. DISCUSSIONOn the tooling side of this approach a problem can occur
in combining the different models. Not every tool is able tocombine different meta-models as this is prerequisite to auto-matically devising the interface code. A possible solution tothis problem is to create a super-meta-model which containsthe elements of the different formalisms[11].
Execution Time (µs) Childlock Off ChildLock On20.000 7500 499920.500 0 1000120.875 7499 021.375 1 0
Table 4. Results for the Logic runnable. The strange resultof the last row is because of a special condition that can onlyoccur in the first execution round.
Execution Time (µs) Childlock Off ChildLock On8.00 6000 30008.250 9000 12000
Table 5. Results for the DC Motor runnable.
In the paper we focused on the calibration of a single ap-plication to be deployed on a single hardware platform type.In real situations multiple types of platforms can be usedwhen deploying such distributed applications. During the de-ployment space exploration the choice of platforms is made.When mixing multiple platforms during deployment multiplecalibration steps are necessary. A calibration for another plat-form can be done by using another “middleware template”,used in Section 4 to generate the platform and interface code,that contains the low-level code to transmit and receive mes-sages over the serial bus and do the measurement of the ex-ecution time. The other transformations remain unchanged.This applies as well for other applications. All transforma-tions are generic and can be used for all applications basedon this workflow.
Validated using hardware measurements!
www.teralabs.org
http://Ansymo.ua.ac.be
Discussion
• Tooling: Combining different formalisms? – Super-meta-model
• More HW platforms, other performance measure? – Use other template
• Limitation: – Caching, pipelines, …
26
www.teralabs.org
http://Ansymo.ua.ac.be
Conclusion
• Problem Statement – Calibration of simulation models
• Solution: – Use MDE techniques (generative) to
calibrate models
27