- Email: [email protected]
Scalable problem-oriented approach for dynamic verification of embedded systems
Proceedings of the 1st IFAC Conference on Embedded Systems, Computational Intelligence and Telematics in Control - CESCIT 2012 3-5 April 2012. Würzburg, Germany
Scalable problem-oriented approach for dynamic verification of embedded systems F. Mendoza ∗ P. Nenninger ∗∗ M. Ruppert ∗∗ J. Becker ∗∗∗ ∗
FZI Forschungszentrum Informatik, Karlsruhe, Germany, [email protected] ∗∗ ABB Corporate Research Center, Ladenburg, Germany, {philipp.nenninger|markus.ruppert}@de.abb.com ∗∗∗ Karlsruhe Institute of Technology, Karlsruhe, Germany, [email protected] Abstract: A model-based problem-oriented approach for the dynamic verification of functional properties of embedded systems is presented. It is a generic and scalable approach, especially useful in systems where embedded devices are tightly coupled to physical processes. A set of modeling guidelines and abstraction layers are proposed that provide a better understanding and visibility of an application’s behavior and resource usage, and of the interactions between the different components of an embedded device and the physical process it interacts with. An application example is given for the design and verification of a digital PID controller that integrates Simulink models, SystemC models and an ARM Cortex-M3 processor emulator. Keywords: Embedded systems, virtual platforms, simulation languages, telematics 1. INTRODUCTION
of a product line due to the addition of functionality in newer versions of a product.
Embedded systems are ubiquitous in any modern process automation system. They are responsible for the computation of processing and communication tasks in the digital domain required to measure, analyze, and control (including feedback control) a process in the physical domain. Due to the tight coupling of domains, computation tasks are directly affected by the behavior of the physical process it interacts with and vice versa. Such systems have been referred to in recent years as cyber-physical systems (CPS), as presented in Lee (2006) and Karsai and Sztipanovits (2008). Applications of CPS are found in many other fields such as automotive, avionics, medicine technology, etc. A physical process is the result of various concurrent dynamic processes, including perturbations such as noise and harmonic disturbances. In order to design an appropriate controller for a physical process, it is a common practice to represent it using mathematical models or domain specific simulation tools that can provide initial information such as maximum operation frequency, non-linearities and discontinuities that must be taken into account. Once a control strategy is selected, the embedded software for a particular microcontroller or DSP architecture is developed. The embedded software, typically developed in C code, is based on software tasks with a sequential execution order of instructions that must interface with the physical processes at specific times. Timing and task activation control are implemented by a real-time operating system (RTOS) with predictable scheduling policies, which is up to now the best-effort technology to specify real-time properties of an embedded system. Additionally, the complexity of the embedded software may increase throughout the lifetime 978-3-902661-97-5/12/$20.00 © 2012 IFAC
Embedded devices have high standards in terms of reliability, security and fault tolerance. Reaching such standards becomes a challenge as the complexity of computational and physical components increases in a CPS. This explains the long and costly development cycles in any type of CPS. It becomes evident that the traditional design approaches are not meant to embrace the characteristics of the physical domain and the digital domain in a unified approach, as presented in Lee (2008). An engineer is left with two different domains that are considered independent in a design stage, but that should interact in a completely reliable and predictable manner in an end-product. In this paper, we propose a model-based scalable problemoriented approach for dynamic verification of embedded systems that encompasses the physical and digital domains of CPS. Our approach is based on modeling and simulation of key aspects of a design in its different design stages. It provides a better understanding and visibility of an application’s behavior and resource usage, and of the interactions between the different components of an embedded device and the physical process it interacts with. Our motivation is to provide improved ways of finding solutions to problems that arise in the development of embedded devices. Such problems are normally too complex or unfeasible to solve with standard hardware prototypes and experimental setups. We demonstrate the feasibility of our approach by enabling system-level HW/SW co-simulation of two well-known model-based tools: Simulink for the physical domain and SystemC for the digital domain. The challenges involved in the co-simulation between both tools along with our proposed solution will be further discussed.
224
10.3182/20120403-3-DE-3010.00011
This paper is organized as follows. Section 2 presents related work on model-based design of embedded systems. Section 3 gives an overview of modeling formalisms for the physical and digital domains along with their simulators. Section 4 presents our methodology for the design and problem solving of embedded systems. Section 5 presents a Simulink/SystemC based framework for applying our methodology, along with definitions for the interfaces and synchronization schemes developed for such purpose. In Sections 6 and 7 an application example from the process control field is presented and discussed. 2. RELATED WORK We will refer to heterogeneous modeling and simulation (M&S) tools to such tools where the physical and digital domains can be modeled and simulated up to some extent. De facto tools in the process control and instrumentation domains are Simulink (MathWorks) and LabVIEW (National Instruments). Their counterpart in the academic domain is Ptolemy II (refer to Eker et al. (2003)) and its recent modal mode extension for continuous time modeling (refer to Derler et al. (2011)). Other examples are the Analog Mixed Signal (AMS) extensions of digital modeling domain tools such as Verilog, VHDL and SystemC. One approach for integrating computational and physical components of CPS systems is based on coupling domain specific M&S tools, such as SystemC for HW/SW models and Simulink for physical models. A common characteristic in any type of co-simulation approach is the existence of one simulator acting as coordinator and in charge of the correct synchronization with other simulators acting as slaves. Therefore, we will classify co-simulation approaches as Simulink centric and SystemC centric, according to which simulator acts as coordinator. SystemC centric approaches use Matlab’s API engine to control and synchronize Simulink time with SystemC time. I/O data transfer is done via source and sink S-Functions located inside a Simulink project. An explicit synchronization scheme based on fixed step sizes is presented in Borland et al. (2005). A more efficient approach (in terms of simulation time) based on SystemC’s event based mechanism is presented in Bouchhima et al. (2007) and in Gheorghe et al. (2009), where the interfaces are formally described. Simulink centric approaches use S-Functions linked to a SystemC kernel to control and synchronize SystemC time with Simulink time. In Hylla et al. (2008), SystemC is used to develop test benches for Simulink models. S-Functions with variable, fixed and inherited sampling time were created according to the functionality of the SystemC model linked to it. A second example is TrueTime library from Cervin and ˚ A rz´en (2009). TrueTime uses SFunctions to call a specially created real time kernel that schedules C snippets or Simulink blocks. Our approach is similar to TrueTime, however we use SystemC, an industry accepted system level modeling language, and are able to implement any type of open source or commercial RTOS kernel inside a virtual platform. In Mendoza et al. (2011) we suggested that Simulink centric approaches provide enhanced usability of SystemC CESCIT 2012 3-5 April 2012. Würzburg, Germany
models in a component library. In this paper, we improved the semantics of the synchronization scheme, making it possible to efficiently simulate any type of Simulink based components with complex SystemC models. 3. MODELING DOMAINS According to Zeigler et al. (2000), a model is defined as a physical, mathematical, or logical representation of a system, entity, phenomenon or process. The representation of a model is done via a set of Models of Computation (MoC) or formalisms, that have a mathematical foundation, support formal or semi-formal reasoning and have a definite semantics. From an engineer’s point of view, formalisms are the means at his disposal in order to describe a system. 3.1 Physical domain Models of the physical domain are described using sets of simultaneous differential and algebraic equations that are piecewise continuous functions of time. They are a natural system specification formalism used in domains such as electrical, mechanical, optical, thermal, etc. Their simulators are classified according to the modeling form they support: causal or non-causal. Causal models are formulated in terms of explicit equations, for example, ordinary differential equations (ODE). Examples of simulators for causal models are Simulink and LabVIEW. Non-causal models are formulated in terms of implicit equations, for example, differential algebraic equations (DAE). Examples of simulators for non-causal models are Modelica and VHLD-AMS. 3.2 Digital domain Models of the digital domain operate on a discrete time basis with outputs that are piecewise constant function of time. We classify them into two categories according to whether the concept of time is considered in their models. Untimed MoC such as synchronous reactive modes and data flow models use simulators where a system’s behavior is evaluated on fixed intervals. Early versions of Ptolemy II and Matlab Stateflow are examples of simulators for digital untimed models. Timed MoC such as timed data flow models, discrete event system specifications (DEVS), Register Transfer Level (RTL) models and Transaction Level Models (TLM) use event based discrete simulators where time advances in variable periods called events. Simulators for digital timed models are commonly used for hardware description languages such as VHDL and SystemC. 4. METHODOLOGY The main abstraction layers of the scalable problemoriented approach for dynamic verification of embedded systems proposed are shown in Figure 1. It considers executable MoCs for the digital and physical domain and relies on simulations in each stage for dynamic verification purposes. Each layer can be implemented independently and scaled according to the verification goals explained in the following subsections. Any abstraction in between the ones presented ahead are valid. Each one provides
225
Digital domain
transfer function with noise disturbances and an AFE as a Σ∆ converter.
Physical domain
The SW Stack is divided into tasks and Interrupt Service Routines (ISR). A SystemC hierarchical module called Platform (showed in Figure 2 as a SystemC module) contains any number of I/O and external interrupt ports whose read/write functions are connected to the co-simulation API. Inside the platform, tasks are placed into SC THREAD wrappers that must yield to the SystemC scheduler via semaphores or timed wait() calls. ISRs are placed into SC METHOD wrappers sensitive to events on their respective external interrupt port. Communication between Tasks and ISRs is done via queues, semaphores or global variables. The activation of Tasks and ISRs is left to SystemC’s cooperative scheduler.
A DACAFE ADCAFE
PLANT
VIC B
UART
DAC GPIO
DACAFE
ADC ADCAFE
PLANT
C MEM C
VIC UART
DAC GPIO
DACAFE
ADC ADCAFE
PLANT
Fig. 1. Abstraction layers in a scalable problem-oriented approach. (A)Specification Model, (B) Transaction Level Model, (C)Virtual Platform Model enhanced visibility of an application’s behavior and resource usage. It enables an engineer to have a better understanding of the interaction between components of an embedded system and the physical process it interacts with. It is especially useful in cases where tests are too complex or unrealizable to be performed with hardware prototypes and experimental setups. In order to demonstrate the feasibility of our approach, we created a system-level HW/SW co-simulation scheme between SystemC and Simulink. Simulink is used to model physical components (right side of Figure 1) and SystemC is used to model computational components of the digital domain (left side of Figure 1). The guidelines to how these models should be created along with the verification goals for each abstraction layer are presented ahead. 4.1 Specification Model A SW Stack is defined as a hardware independent implementation developed in C that describes the functionality of an application that will later on be executed in an embedded system. It typically describes signal processing and control algorithms implemented manually or generated automatically from higher-level modes of state charts and dataflow models. In order for the SW stack to interact with the physical domain and vice versa, read/write functions from a co-simulation API (see Figure 2) are available. Data going in and out the physical domain must pass through DAC and ADC Analog Front Ends (AFE) respectively. The plant and AFE models are developed in Simulink and are simulated with a Runge-Kutta variable step solver. The model complexity of the physical domain can be as complex as required. For example, a plant described as a CESCIT 2012 3-5 April 2012. Würzburg, Germany
The verification goal on this level is the correct SW stack application functionality. Common problems that can be identified are the incorrect implementation of control or signal processing algorithms and deadlocks. Initial studies on the influence of noise and distortions form the physical process on the SW stack can be carried out. Since the SW Stack can also include estimates of timing behavior, its influence on the physical process can be observed. The advantage of this level of modeling abstraction is high simulation speed, thus a wide range of scenarios can be easily simulated. 4.2 Transaction Level Model A Transaction Level Model has a clear separation between communication and computation components. Computation is done by the SW stack and communication to peripherals is done via SW drivers that access memory mapped I/O addresses. Peripherals are allowed to request polling from the SW stack via interrupt driven I/Os that trigger ISR calls in the SW Stack. Communication details are completely hidden to the SW Stack and are handled via a loosely timed SystemC TLM 2.0 bus and adapters. A Transaction Level Model closely resembles HW and SW components of a real embedded system. Therefore, embedded software and drivers can be created or reused from available legacy code. The I/O peripherals such as a VIC 1 , GPIO, UART, ADC and DAC are added along with a loosely timed TLM2.0 bus model, as shown in Figure 1. Functionality of peripherals is modeled based on technical specification available from IC providers. Typically, an engineer does not need to model the complete functionality of a peripheral, thus the modeling effort is low. Additionally, SW drivers for each peripheral must be created to simplify the development of embedded software in the SW Stack. Function calls to the co-simulation API are removed from the SW Stack and are placed in ADC and DAC peripherals. A SW Stack will now have access to I/O data from Simulink via SW drivers that access the ADC and DAC. Additionally, due to the use of SystemC and TLM 2.0 standards, timing behavior estimates of the SW Stack, bus transfers and I/O peripherals can be included in the models. 1
Vector Interrupt Controller, the term was taken from ARM architectural descriptions
226
The verification goal on this level is the functionality of the communication layer. It provides visibility on the bus and the transactions between the SW stack and peripherals. Typical problems that can be identified are communication bottlenecks caused by a high number of calls to certain peripherals. SW drivers can be developed and tested at this point. Since the digital model also contains estimates for processing and communication times, their influence on the physical process and vice versa can be observed on simulation traces.
Simulink Framework Simulink Block
S-Function Middleware
Co-Simulation API SystemC Kernel
SystemC Module
4.3 Virtual Platform Model Fig. 2. Interfaces for Simulink/SystemC co-simulation In a Virtual Platform model, a SW Stack made up of tasks, ISRs and SW drivers is compiled to a specific instruction set architecture. Figure 1 shows how the SW Stack is replaced by a µC module, equivalent to a processor emulator, and a memory model where native code for the selected processor architecture is stored. A processor emulator is able to efficiently execute native code in an instruction-accurate manner. The same native code can be latter on executed by a real processor. The emulation and Just-in-Time compiling principles behind the µC module are out of the scope of this paper. In order to include a processor emulator inside a Virtual Platform Model, it must provide C/C++ compatible APIs that are called from SystemC for data transfer and control. We opted for using Open Virtual Platform processor models from Imperas. Their processor models provide the required APIs and SystemC TLM 2.0 interfaces which make it possible to seamlessly integrate any type and number of processor emulators inside a Virtual Platform Model. A Virtual Platform Model provides the necessary HW infrastructure to natively support the execution of an RTOS inside the µC module. However, it is often the case that the memory mapped address space of the HW infrastructure does not match exactly that of an available RTOS, in which case porting effort is required. SystemC constructs that were used in the SW Stack of a Transaction Level Model, such as semaphores, queues, and timed delays, are typically supported by any RTOS. Therefore, the advantage of using an RTOS is a straightforward translation of the SW Stack to a specific RTOS implementation. SystemC is no longer used for scheduling and execution of the embedded software. Instead, an RTOS specific scheduler is used to natively execute computations. The verification goals on this level are the RTOS integration and the full system functionality. It is particularly useful to understand the complex interaction between the physical domain and an RTOS. Common problems that can be identified are stack overflows, race conditions and priority inversion problems. Since the embedded software is already complied for a specific microcontroller architecture, metrics for a HW implementation such as memory footprint of an RTOS and its embedded software are easily obtained. Estimate performance metrics can also be obtained, however they must be interpreted with care since various factors can lead to high inaccuracies. Such considerations are: (1) dynamic effects of pipeline and cache are not considered by a processor emulator and CESCIT 2012 3-5 April 2012. Würzburg, Germany
(2) timing for peripherals and bus delays depend on the correctness of the estimates given by an engineer. 5. CO-SIMULATION FRAMEWORK Co-simulation between SystemC and Simulink is carried out by a set of well-defined interfaces, and a time and data synchronization scheme. It enables dynamic verification of CPS modeled in any of the abstractions shown in Section 4. The advantage of our semantics is that they do not affect the modeling capabilities of SystemC or Simulink. An engineer has complete freedom of implementing any type of models and modeling style required as long as they are natively supported by their simulator. 5.1 Interface definitions Figure 2 shows the interfaces that make it possible to reflect the structure and behavior of a SystemC hierarchical module, namely a Platform (refer to Section 4.1), into a Simulink block. It is also possible to include more SystemC modules as Simulink blocks (for further details refer to Mendoza et al. (2011)). We use S-Functions developed in C ++ to extend the functionality of a Simulink block. The communication between an S-Function and a SystemC kernel is done via an interprocess communication middleware such as TCP/IP or shared memory. However, it is also possible to statically link a SystemC kernel to an S-Function, in which case no middleware is required and communication is done sharing by pointers to a common memory space. The co-simulation API is a SystemC hierarchical channel where the I/O and external interrupt ports of a SystemC Platform are connected to and linked to their respective counterparts as ports in a Simulink block. Additionally, the co-simulation API provides a control channel used by an S-Function to parameterize, query and control a SystemC kernel. 5.2 Synchronization scheme The co-simulation semantics of Simulink and SystemC are implemented inside a parameterizable S-Function and dictate how the data and time synchronization is performed. The sampling type chosen for an S-Function is crucial for a correct and efficient simulation, since it determines how Simulink’s simulation engine will interact with a SystemC kernel. For instance, a discrete sampled S-Function is called in fixed simulation steps and is an
227
-0.6 s+0.1
. . .
Step
. . .
Setpoint ADC_2 Out1
SystemC Time
A
B
C
D
Disturbance
ADC_1
.. .
D, Nxt
D,
D, Nxt
4
Re q
3
D, R eq
Re q D,
D, Nxt
D, Req
D, Nxt
2
1
Simulink Time
. . .
PID OFF/ON
DAC_1
IntExt_1 ARM Cortex-M3 Digital Controller
Volts
°C
5 s+0.1
Scope
Plant Sensor Volts
0.05
°C
Global Time 0
e1
e2
e3
e4
Fig. 4. Temperature-control system State event
Time advance
Context switch
Interrupt
Fig. 3. Transition diagram for Simulink/SystemC synchronization scheme inefficient way to transfer data with SystemC’s event based simulation kernel. A variable sampled S-Function is more efficient since its next time to trigger can be programmed according to SystemC’s event queue, avoiding unnecessary synchronization steps; however, the next time to trigger cannot be reprogrammed if a newer event on the queue appears. The third sampling type available, continuous sampling, is used commonly for physical models where time advances in variable steps only after scurrying for zero-crossing conditions in minor simulation time steps that go forward in the simulation time. We exploit the zero-crossing detection functionality of continuous sampling S-Functions to dynamically detect the times at which a SystemC kernel requires synchronization with Simulink. Synchronization times are determined on run-time based on timed events registered in SystemC’s event queue 2 and on external events from Simulink (interrupts) to which SystemC processes are sensitive. Since not every timed even on SystemC’s queue requires synchronization with Simulink, we implemented a search algorithm that looks only for events triggered by processes owned by ADC and DAC peripherals. The transition diagram in Figure 3 shows how data and time are synchronized between Simulink and SystemC. Context switches happen on state events determined by SystemC’s event queue (e1 and e3 ) and on events from external interrupt signals (e2 ). After initialization (states (1) and (A)), Simulink time remains ahead of SystemC time. Simulink time advances up to state (2), where I/O data is transfered and context is switched to SystemC. SystemC time advances from state (A) to (B), where I/O data is transfered and context is switched back to Simulink. Zero-crossing detectors detect the precise time external interrupts occur, in which case additional state events are triggered (states (3) and (C)). Since the synchronization scheme is event-driven and supports interrupt detection, simulations are efficient and no I/O data is lost. 6. APPLICATION EXAMPLE We present a generic example of the proposed methods and tools applied in the design and verification of a digital PID controller for a temperature-control system (Phillips and Harbor (1991)). Three SystemC based digital
controllers were created following the abstraction layers presented in Section 4. They were made available as components of a Simulink library and used in the test setup from Figure 4 to verify the behavior of their PID algorithm implementations for controlling the temperature of a physical model described in Simulink. The design and verification procedure of a digital PID controller algorithm (implemented in C) using available Specification, Transaction Level and Virtual Platform Model infrastructures will be further explained. In the Specification Model, the PID algorithm is inserted in the SW Stack as a task with direct access to I/O ports for data transfer with Simulink. Additionally, the SW Stack includes one ISR sensitive to an external interrupt that toggles the activation of the PID task. Time advances in the model via a wait(100,SC MS) statement in the PID task. In the Transaction Level Model, the PID algorithm is inserted in the SW Stack as a task with access to peripheral SW drivers. The ADC is configured to sample input data from Simulink on a 100msec rate with 16-bit resolution. ISRs for the ADC and one external interrupt are added. The PID task activation is controlled by a semaphore trigged by the ADC ISR, at which point the computations from the PID algorithm are executed and data is sent to Simulink via DAC SW drivers. The Virtual Platform Model contains an ARM Cortex-M3 processor emulator (OVP processor model from Imperas). The SW Stack contains a ported distribution of FreeRTOS. The PID algorithm, ADC configuration and ISRs for ADC and external interrupts are included to the SW Stack in a similar procedure to the Transaction Level Model. The main difference is that SystemC specific constructs are replaced by FreeRTOS constructs. The complete SW Stack is cross-complied and loaded to a memory peripheral, where it will be fetched by the ARM Cortex-M3 model on run-time. Figure 5 shows the simulation results for each of the three SystemC based models controlling the temperature of the Simulink physical plant models from Figure 4. For comparison purposes, the simulation results from a reference model developed in Simulink with a PID block from the discrete time toolbox are also shown. All simulations were done using a standard desktop PC. The following table lists the simulation times for each model:
2 a non-intrusive mechanism in simContextProxy was implemented that allows a friend class to look into the event queue and to obtain the name of the SystemC object instance responsible for each event
CESCIT 2012 3-5 April 2012. Würzburg, Germany
228
Model Name Simulink Reference Model Specification Model Transaction Level Model Virtual Platform Model
Simulation Time 0.652 sec 0.888 sec 2.369 sec 11.825 sec
SystemC communication and IP models which will promote the availability of models and their implementation in other industries. This work demonstrates that once a model infrastructure is available, its implementation in the design and verification of embedded systems for domainspecific applications is viable.
Controller Output/V
2 Simulink Reference Model Specification Model Transaction Level Model Virtual Platform Model
1.5
1
0.5
0
0
10
20
30
40
50 Time/sec
60
70
80
90
100
REFERENCES
System Output/°C
25 20 15 ←Disturbance
10
PID
→
OFF
← PIDON
Simulink Reference Model Specification Model Transaction Level Model Virtual Platform Model
5 0
0
10
20
30
40
50 Time/sec
60
70
80
90
100
Fig. 5. Simulation results of the three SystemC based digital controllers and a Simulink reference model Figure 6 presents the relative temperature differences of the physical plant models controlled by our SystemC based models. The results are presented with respect to a Simulink reference model. Our PID algorithm implementation is different to the one used by Simulink’s PID block. It becomes evident when the PID models start (100-125% peeks between 1-1.1sec that are not shown in the graph) and when they are reseted. An anti-windup PID algorithm implementation could be used to solve this issue. It is also interesting to see that relative differences are bigger for the Virtual Platform Model, which computes the same PID algorithm implementation, however complied with another compiler for a different processor architecture. |Relative Difference|
0.02 Specification Model Transaction Level Model Virtual Platform Model
0.015
0.01
0.005
0
0
10
20
30
40
50 Time/sec
60
70
80
90
100
Fig. 6. Relative output temperature differences with respect to a Simulink reference model 7. CONCLUSIONS AND OUTLOOK Model-based approaches for the design and verification of CPS are a promising solution to understand their complexity, identify and solve potential problems through abstraction, and to enhance the productivity of engineers. They can also help in the transition to implementation solutions through a better understanding of a system and its parts. This paper exposed the challenges involved in the integration of domain specific modeling languages and proposed a possible solution based on Simulink and SystemC. Simulink is already a de facto tool in many industries, thus models are widely available. SystemC models are already available in the commercial and academic domain, but they are specialized for particular applications. There is currently much work being done in the standardization of CESCIT 2012 3-5 April 2012. Würzburg, Germany
Borland, J.F., Thibeault, C., and Zilic, Z. (2005). Using Matlab and Simulink in SystemC verification environment. In Proceedings of Design and Verification Conference, DVCon05. Bouchhima, F., Nicolescu, G., Aboulhamid, E.M., and Abid, M. (2007). Generic discretecontinuous simulation model for accurate validation in heterogeneous systems design. Microelectronics Journal, 38(6-7), 805–815. Cervin, A. and ˚ A rz´en, K.E. (2009). TrueTime: Simulation Tool for Performance Analysis of Real-Time Embedded Systems. In G. Nicolescu and P.J. Mosterman (eds.), Model-Based Design for Embedded Systems. CRC Press. Derler, P., Lee, E.A., and Sangiovanni-Vincentelli, A. (2011). Addressing Modeling Challenges in CyberPhysical Systems. Technical Report UCB/EECS-201117, EECS Department University of California, Berkeley, Berkeley. Eker, J., Janneck, J., Lee, E.A., Liu, J., Liu, X., Ludvig, J., Sachs, S., and Xiong, Y. (2003). Taming heterogeneity the Ptolemy approach. Proceedings of the IEEE, 91(1), 127–144. Gheorghe, L., Nicolescu, G., and Boucheneb, H. (2009). Generic Methodology for the Design of Continuous/Discrete Co-Simulation Tools. In G. Nicolescu and P.J. Mosterman (eds.), Model-Based Design for Embedded Systems. CRC Press. Hylla, K., Oetjens, J.H., and Nebel, W. (2008). Using SystemC for an extended MATLAB/Simulink verification flow. In 2008 Forum on Specification, Verification and Design Languages, 221–226. IEEE. Karsai, G. and Sztipanovits, J. (2008). ModelIntegrated Development of Cyber-Physical Systems. In U. Brinkschulte, T. Givargis, and S. Russo (eds.), Software Technologies for Embedded and Ubiquitous Systems, volume 5287 of Lecture Notes in Computer Science, 46–54. Springer Berlin / Heidelberg. Lee, E.A. (2006). Cyber-Physical Systems -Are Computing Foundations Adequate? In NSF Workshop On Cyber-Physical Systems: Research Motivation, Techniques and Roadmap. Lee, E.A. (2008). Cyber Physical Systems: Design Challenges. In International Symposium on Object/Component/Service-Oriented Real-Time Distributed Computing (ISORC). Mendoza, F., Kollner, C., Becker, J., and MullerGlaser, K.D. (2011). An automated approach to SystemC/Simulink co-simulation. In 2011 22nd IEEE International Symposium on Rapid System Prototyping, 135–141. IEEE. Phillips, C.L. and Harbor, R.D. (1991). Feedback control systems. Prentice Hall, second edi edition. Zeigler, B.P., Praehofer, H., and Kim, T.G. (2000). Theory of modeling and simulation, volume 100. Academic Press New York.
229
Scalable problem-oriented approach for dynamic verification of embedded systems F. Mendoza ∗ P. Nenninger ∗∗ M. Ruppert ∗∗ J. Becker ∗∗∗ ∗
FZI Forschungszentrum Informatik, Karlsruhe, Germany, [email protected] ∗∗ ABB Corporate Research Center, Ladenburg, Germany, {philipp.nenninger|markus.ruppert}@de.abb.com ∗∗∗ Karlsruhe Institute of Technology, Karlsruhe, Germany, [email protected] Abstract: A model-based problem-oriented approach for the dynamic verification of functional properties of embedded systems is presented. It is a generic and scalable approach, especially useful in systems where embedded devices are tightly coupled to physical processes. A set of modeling guidelines and abstraction layers are proposed that provide a better understanding and visibility of an application’s behavior and resource usage, and of the interactions between the different components of an embedded device and the physical process it interacts with. An application example is given for the design and verification of a digital PID controller that integrates Simulink models, SystemC models and an ARM Cortex-M3 processor emulator. Keywords: Embedded systems, virtual platforms, simulation languages, telematics 1. INTRODUCTION
of a product line due to the addition of functionality in newer versions of a product.
Embedded systems are ubiquitous in any modern process automation system. They are responsible for the computation of processing and communication tasks in the digital domain required to measure, analyze, and control (including feedback control) a process in the physical domain. Due to the tight coupling of domains, computation tasks are directly affected by the behavior of the physical process it interacts with and vice versa. Such systems have been referred to in recent years as cyber-physical systems (CPS), as presented in Lee (2006) and Karsai and Sztipanovits (2008). Applications of CPS are found in many other fields such as automotive, avionics, medicine technology, etc. A physical process is the result of various concurrent dynamic processes, including perturbations such as noise and harmonic disturbances. In order to design an appropriate controller for a physical process, it is a common practice to represent it using mathematical models or domain specific simulation tools that can provide initial information such as maximum operation frequency, non-linearities and discontinuities that must be taken into account. Once a control strategy is selected, the embedded software for a particular microcontroller or DSP architecture is developed. The embedded software, typically developed in C code, is based on software tasks with a sequential execution order of instructions that must interface with the physical processes at specific times. Timing and task activation control are implemented by a real-time operating system (RTOS) with predictable scheduling policies, which is up to now the best-effort technology to specify real-time properties of an embedded system. Additionally, the complexity of the embedded software may increase throughout the lifetime 978-3-902661-97-5/12/$20.00 © 2012 IFAC
Embedded devices have high standards in terms of reliability, security and fault tolerance. Reaching such standards becomes a challenge as the complexity of computational and physical components increases in a CPS. This explains the long and costly development cycles in any type of CPS. It becomes evident that the traditional design approaches are not meant to embrace the characteristics of the physical domain and the digital domain in a unified approach, as presented in Lee (2008). An engineer is left with two different domains that are considered independent in a design stage, but that should interact in a completely reliable and predictable manner in an end-product. In this paper, we propose a model-based scalable problemoriented approach for dynamic verification of embedded systems that encompasses the physical and digital domains of CPS. Our approach is based on modeling and simulation of key aspects of a design in its different design stages. It provides a better understanding and visibility of an application’s behavior and resource usage, and of the interactions between the different components of an embedded device and the physical process it interacts with. Our motivation is to provide improved ways of finding solutions to problems that arise in the development of embedded devices. Such problems are normally too complex or unfeasible to solve with standard hardware prototypes and experimental setups. We demonstrate the feasibility of our approach by enabling system-level HW/SW co-simulation of two well-known model-based tools: Simulink for the physical domain and SystemC for the digital domain. The challenges involved in the co-simulation between both tools along with our proposed solution will be further discussed.
224
10.3182/20120403-3-DE-3010.00011
This paper is organized as follows. Section 2 presents related work on model-based design of embedded systems. Section 3 gives an overview of modeling formalisms for the physical and digital domains along with their simulators. Section 4 presents our methodology for the design and problem solving of embedded systems. Section 5 presents a Simulink/SystemC based framework for applying our methodology, along with definitions for the interfaces and synchronization schemes developed for such purpose. In Sections 6 and 7 an application example from the process control field is presented and discussed. 2. RELATED WORK We will refer to heterogeneous modeling and simulation (M&S) tools to such tools where the physical and digital domains can be modeled and simulated up to some extent. De facto tools in the process control and instrumentation domains are Simulink (MathWorks) and LabVIEW (National Instruments). Their counterpart in the academic domain is Ptolemy II (refer to Eker et al. (2003)) and its recent modal mode extension for continuous time modeling (refer to Derler et al. (2011)). Other examples are the Analog Mixed Signal (AMS) extensions of digital modeling domain tools such as Verilog, VHDL and SystemC. One approach for integrating computational and physical components of CPS systems is based on coupling domain specific M&S tools, such as SystemC for HW/SW models and Simulink for physical models. A common characteristic in any type of co-simulation approach is the existence of one simulator acting as coordinator and in charge of the correct synchronization with other simulators acting as slaves. Therefore, we will classify co-simulation approaches as Simulink centric and SystemC centric, according to which simulator acts as coordinator. SystemC centric approaches use Matlab’s API engine to control and synchronize Simulink time with SystemC time. I/O data transfer is done via source and sink S-Functions located inside a Simulink project. An explicit synchronization scheme based on fixed step sizes is presented in Borland et al. (2005). A more efficient approach (in terms of simulation time) based on SystemC’s event based mechanism is presented in Bouchhima et al. (2007) and in Gheorghe et al. (2009), where the interfaces are formally described. Simulink centric approaches use S-Functions linked to a SystemC kernel to control and synchronize SystemC time with Simulink time. In Hylla et al. (2008), SystemC is used to develop test benches for Simulink models. S-Functions with variable, fixed and inherited sampling time were created according to the functionality of the SystemC model linked to it. A second example is TrueTime library from Cervin and ˚ A rz´en (2009). TrueTime uses SFunctions to call a specially created real time kernel that schedules C snippets or Simulink blocks. Our approach is similar to TrueTime, however we use SystemC, an industry accepted system level modeling language, and are able to implement any type of open source or commercial RTOS kernel inside a virtual platform. In Mendoza et al. (2011) we suggested that Simulink centric approaches provide enhanced usability of SystemC CESCIT 2012 3-5 April 2012. Würzburg, Germany
models in a component library. In this paper, we improved the semantics of the synchronization scheme, making it possible to efficiently simulate any type of Simulink based components with complex SystemC models. 3. MODELING DOMAINS According to Zeigler et al. (2000), a model is defined as a physical, mathematical, or logical representation of a system, entity, phenomenon or process. The representation of a model is done via a set of Models of Computation (MoC) or formalisms, that have a mathematical foundation, support formal or semi-formal reasoning and have a definite semantics. From an engineer’s point of view, formalisms are the means at his disposal in order to describe a system. 3.1 Physical domain Models of the physical domain are described using sets of simultaneous differential and algebraic equations that are piecewise continuous functions of time. They are a natural system specification formalism used in domains such as electrical, mechanical, optical, thermal, etc. Their simulators are classified according to the modeling form they support: causal or non-causal. Causal models are formulated in terms of explicit equations, for example, ordinary differential equations (ODE). Examples of simulators for causal models are Simulink and LabVIEW. Non-causal models are formulated in terms of implicit equations, for example, differential algebraic equations (DAE). Examples of simulators for non-causal models are Modelica and VHLD-AMS. 3.2 Digital domain Models of the digital domain operate on a discrete time basis with outputs that are piecewise constant function of time. We classify them into two categories according to whether the concept of time is considered in their models. Untimed MoC such as synchronous reactive modes and data flow models use simulators where a system’s behavior is evaluated on fixed intervals. Early versions of Ptolemy II and Matlab Stateflow are examples of simulators for digital untimed models. Timed MoC such as timed data flow models, discrete event system specifications (DEVS), Register Transfer Level (RTL) models and Transaction Level Models (TLM) use event based discrete simulators where time advances in variable periods called events. Simulators for digital timed models are commonly used for hardware description languages such as VHDL and SystemC. 4. METHODOLOGY The main abstraction layers of the scalable problemoriented approach for dynamic verification of embedded systems proposed are shown in Figure 1. It considers executable MoCs for the digital and physical domain and relies on simulations in each stage for dynamic verification purposes. Each layer can be implemented independently and scaled according to the verification goals explained in the following subsections. Any abstraction in between the ones presented ahead are valid. Each one provides
225
Digital domain
transfer function with noise disturbances and an AFE as a Σ∆ converter.
Physical domain
The SW Stack is divided into tasks and Interrupt Service Routines (ISR). A SystemC hierarchical module called Platform (showed in Figure 2 as a SystemC module) contains any number of I/O and external interrupt ports whose read/write functions are connected to the co-simulation API. Inside the platform, tasks are placed into SC THREAD wrappers that must yield to the SystemC scheduler via semaphores or timed wait() calls. ISRs are placed into SC METHOD wrappers sensitive to events on their respective external interrupt port. Communication between Tasks and ISRs is done via queues, semaphores or global variables. The activation of Tasks and ISRs is left to SystemC’s cooperative scheduler.
A DACAFE ADCAFE
PLANT
VIC B
UART
DAC GPIO
DACAFE
ADC ADCAFE
PLANT
C MEM C
VIC UART
DAC GPIO
DACAFE
ADC ADCAFE
PLANT
Fig. 1. Abstraction layers in a scalable problem-oriented approach. (A)Specification Model, (B) Transaction Level Model, (C)Virtual Platform Model enhanced visibility of an application’s behavior and resource usage. It enables an engineer to have a better understanding of the interaction between components of an embedded system and the physical process it interacts with. It is especially useful in cases where tests are too complex or unrealizable to be performed with hardware prototypes and experimental setups. In order to demonstrate the feasibility of our approach, we created a system-level HW/SW co-simulation scheme between SystemC and Simulink. Simulink is used to model physical components (right side of Figure 1) and SystemC is used to model computational components of the digital domain (left side of Figure 1). The guidelines to how these models should be created along with the verification goals for each abstraction layer are presented ahead. 4.1 Specification Model A SW Stack is defined as a hardware independent implementation developed in C that describes the functionality of an application that will later on be executed in an embedded system. It typically describes signal processing and control algorithms implemented manually or generated automatically from higher-level modes of state charts and dataflow models. In order for the SW stack to interact with the physical domain and vice versa, read/write functions from a co-simulation API (see Figure 2) are available. Data going in and out the physical domain must pass through DAC and ADC Analog Front Ends (AFE) respectively. The plant and AFE models are developed in Simulink and are simulated with a Runge-Kutta variable step solver. The model complexity of the physical domain can be as complex as required. For example, a plant described as a CESCIT 2012 3-5 April 2012. Würzburg, Germany
The verification goal on this level is the correct SW stack application functionality. Common problems that can be identified are the incorrect implementation of control or signal processing algorithms and deadlocks. Initial studies on the influence of noise and distortions form the physical process on the SW stack can be carried out. Since the SW Stack can also include estimates of timing behavior, its influence on the physical process can be observed. The advantage of this level of modeling abstraction is high simulation speed, thus a wide range of scenarios can be easily simulated. 4.2 Transaction Level Model A Transaction Level Model has a clear separation between communication and computation components. Computation is done by the SW stack and communication to peripherals is done via SW drivers that access memory mapped I/O addresses. Peripherals are allowed to request polling from the SW stack via interrupt driven I/Os that trigger ISR calls in the SW Stack. Communication details are completely hidden to the SW Stack and are handled via a loosely timed SystemC TLM 2.0 bus and adapters. A Transaction Level Model closely resembles HW and SW components of a real embedded system. Therefore, embedded software and drivers can be created or reused from available legacy code. The I/O peripherals such as a VIC 1 , GPIO, UART, ADC and DAC are added along with a loosely timed TLM2.0 bus model, as shown in Figure 1. Functionality of peripherals is modeled based on technical specification available from IC providers. Typically, an engineer does not need to model the complete functionality of a peripheral, thus the modeling effort is low. Additionally, SW drivers for each peripheral must be created to simplify the development of embedded software in the SW Stack. Function calls to the co-simulation API are removed from the SW Stack and are placed in ADC and DAC peripherals. A SW Stack will now have access to I/O data from Simulink via SW drivers that access the ADC and DAC. Additionally, due to the use of SystemC and TLM 2.0 standards, timing behavior estimates of the SW Stack, bus transfers and I/O peripherals can be included in the models. 1
Vector Interrupt Controller, the term was taken from ARM architectural descriptions
226
The verification goal on this level is the functionality of the communication layer. It provides visibility on the bus and the transactions between the SW stack and peripherals. Typical problems that can be identified are communication bottlenecks caused by a high number of calls to certain peripherals. SW drivers can be developed and tested at this point. Since the digital model also contains estimates for processing and communication times, their influence on the physical process and vice versa can be observed on simulation traces.
Simulink Framework Simulink Block
S-Function Middleware
Co-Simulation API SystemC Kernel
SystemC Module
4.3 Virtual Platform Model Fig. 2. Interfaces for Simulink/SystemC co-simulation In a Virtual Platform model, a SW Stack made up of tasks, ISRs and SW drivers is compiled to a specific instruction set architecture. Figure 1 shows how the SW Stack is replaced by a µC module, equivalent to a processor emulator, and a memory model where native code for the selected processor architecture is stored. A processor emulator is able to efficiently execute native code in an instruction-accurate manner. The same native code can be latter on executed by a real processor. The emulation and Just-in-Time compiling principles behind the µC module are out of the scope of this paper. In order to include a processor emulator inside a Virtual Platform Model, it must provide C/C++ compatible APIs that are called from SystemC for data transfer and control. We opted for using Open Virtual Platform processor models from Imperas. Their processor models provide the required APIs and SystemC TLM 2.0 interfaces which make it possible to seamlessly integrate any type and number of processor emulators inside a Virtual Platform Model. A Virtual Platform Model provides the necessary HW infrastructure to natively support the execution of an RTOS inside the µC module. However, it is often the case that the memory mapped address space of the HW infrastructure does not match exactly that of an available RTOS, in which case porting effort is required. SystemC constructs that were used in the SW Stack of a Transaction Level Model, such as semaphores, queues, and timed delays, are typically supported by any RTOS. Therefore, the advantage of using an RTOS is a straightforward translation of the SW Stack to a specific RTOS implementation. SystemC is no longer used for scheduling and execution of the embedded software. Instead, an RTOS specific scheduler is used to natively execute computations. The verification goals on this level are the RTOS integration and the full system functionality. It is particularly useful to understand the complex interaction between the physical domain and an RTOS. Common problems that can be identified are stack overflows, race conditions and priority inversion problems. Since the embedded software is already complied for a specific microcontroller architecture, metrics for a HW implementation such as memory footprint of an RTOS and its embedded software are easily obtained. Estimate performance metrics can also be obtained, however they must be interpreted with care since various factors can lead to high inaccuracies. Such considerations are: (1) dynamic effects of pipeline and cache are not considered by a processor emulator and CESCIT 2012 3-5 April 2012. Würzburg, Germany
(2) timing for peripherals and bus delays depend on the correctness of the estimates given by an engineer. 5. CO-SIMULATION FRAMEWORK Co-simulation between SystemC and Simulink is carried out by a set of well-defined interfaces, and a time and data synchronization scheme. It enables dynamic verification of CPS modeled in any of the abstractions shown in Section 4. The advantage of our semantics is that they do not affect the modeling capabilities of SystemC or Simulink. An engineer has complete freedom of implementing any type of models and modeling style required as long as they are natively supported by their simulator. 5.1 Interface definitions Figure 2 shows the interfaces that make it possible to reflect the structure and behavior of a SystemC hierarchical module, namely a Platform (refer to Section 4.1), into a Simulink block. It is also possible to include more SystemC modules as Simulink blocks (for further details refer to Mendoza et al. (2011)). We use S-Functions developed in C ++ to extend the functionality of a Simulink block. The communication between an S-Function and a SystemC kernel is done via an interprocess communication middleware such as TCP/IP or shared memory. However, it is also possible to statically link a SystemC kernel to an S-Function, in which case no middleware is required and communication is done sharing by pointers to a common memory space. The co-simulation API is a SystemC hierarchical channel where the I/O and external interrupt ports of a SystemC Platform are connected to and linked to their respective counterparts as ports in a Simulink block. Additionally, the co-simulation API provides a control channel used by an S-Function to parameterize, query and control a SystemC kernel. 5.2 Synchronization scheme The co-simulation semantics of Simulink and SystemC are implemented inside a parameterizable S-Function and dictate how the data and time synchronization is performed. The sampling type chosen for an S-Function is crucial for a correct and efficient simulation, since it determines how Simulink’s simulation engine will interact with a SystemC kernel. For instance, a discrete sampled S-Function is called in fixed simulation steps and is an
227
-0.6 s+0.1
. . .
Step
. . .
Setpoint ADC_2 Out1
SystemC Time
A
B
C
D
Disturbance
ADC_1
.. .
D, Nxt
D,
D, Nxt
4
Re q
3
D, R eq
Re q D,
D, Nxt
D, Req
D, Nxt
2
1
Simulink Time
. . .
PID OFF/ON
DAC_1
IntExt_1 ARM Cortex-M3 Digital Controller
Volts
°C
5 s+0.1
Scope
Plant Sensor Volts
0.05
°C
Global Time 0
e1
e2
e3
e4
Fig. 4. Temperature-control system State event
Time advance
Context switch
Interrupt
Fig. 3. Transition diagram for Simulink/SystemC synchronization scheme inefficient way to transfer data with SystemC’s event based simulation kernel. A variable sampled S-Function is more efficient since its next time to trigger can be programmed according to SystemC’s event queue, avoiding unnecessary synchronization steps; however, the next time to trigger cannot be reprogrammed if a newer event on the queue appears. The third sampling type available, continuous sampling, is used commonly for physical models where time advances in variable steps only after scurrying for zero-crossing conditions in minor simulation time steps that go forward in the simulation time. We exploit the zero-crossing detection functionality of continuous sampling S-Functions to dynamically detect the times at which a SystemC kernel requires synchronization with Simulink. Synchronization times are determined on run-time based on timed events registered in SystemC’s event queue 2 and on external events from Simulink (interrupts) to which SystemC processes are sensitive. Since not every timed even on SystemC’s queue requires synchronization with Simulink, we implemented a search algorithm that looks only for events triggered by processes owned by ADC and DAC peripherals. The transition diagram in Figure 3 shows how data and time are synchronized between Simulink and SystemC. Context switches happen on state events determined by SystemC’s event queue (e1 and e3 ) and on events from external interrupt signals (e2 ). After initialization (states (1) and (A)), Simulink time remains ahead of SystemC time. Simulink time advances up to state (2), where I/O data is transfered and context is switched to SystemC. SystemC time advances from state (A) to (B), where I/O data is transfered and context is switched back to Simulink. Zero-crossing detectors detect the precise time external interrupts occur, in which case additional state events are triggered (states (3) and (C)). Since the synchronization scheme is event-driven and supports interrupt detection, simulations are efficient and no I/O data is lost. 6. APPLICATION EXAMPLE We present a generic example of the proposed methods and tools applied in the design and verification of a digital PID controller for a temperature-control system (Phillips and Harbor (1991)). Three SystemC based digital
controllers were created following the abstraction layers presented in Section 4. They were made available as components of a Simulink library and used in the test setup from Figure 4 to verify the behavior of their PID algorithm implementations for controlling the temperature of a physical model described in Simulink. The design and verification procedure of a digital PID controller algorithm (implemented in C) using available Specification, Transaction Level and Virtual Platform Model infrastructures will be further explained. In the Specification Model, the PID algorithm is inserted in the SW Stack as a task with direct access to I/O ports for data transfer with Simulink. Additionally, the SW Stack includes one ISR sensitive to an external interrupt that toggles the activation of the PID task. Time advances in the model via a wait(100,SC MS) statement in the PID task. In the Transaction Level Model, the PID algorithm is inserted in the SW Stack as a task with access to peripheral SW drivers. The ADC is configured to sample input data from Simulink on a 100msec rate with 16-bit resolution. ISRs for the ADC and one external interrupt are added. The PID task activation is controlled by a semaphore trigged by the ADC ISR, at which point the computations from the PID algorithm are executed and data is sent to Simulink via DAC SW drivers. The Virtual Platform Model contains an ARM Cortex-M3 processor emulator (OVP processor model from Imperas). The SW Stack contains a ported distribution of FreeRTOS. The PID algorithm, ADC configuration and ISRs for ADC and external interrupts are included to the SW Stack in a similar procedure to the Transaction Level Model. The main difference is that SystemC specific constructs are replaced by FreeRTOS constructs. The complete SW Stack is cross-complied and loaded to a memory peripheral, where it will be fetched by the ARM Cortex-M3 model on run-time. Figure 5 shows the simulation results for each of the three SystemC based models controlling the temperature of the Simulink physical plant models from Figure 4. For comparison purposes, the simulation results from a reference model developed in Simulink with a PID block from the discrete time toolbox are also shown. All simulations were done using a standard desktop PC. The following table lists the simulation times for each model:
2 a non-intrusive mechanism in simContextProxy was implemented that allows a friend class to look into the event queue and to obtain the name of the SystemC object instance responsible for each event
CESCIT 2012 3-5 April 2012. Würzburg, Germany
228
Model Name Simulink Reference Model Specification Model Transaction Level Model Virtual Platform Model
Simulation Time 0.652 sec 0.888 sec 2.369 sec 11.825 sec
SystemC communication and IP models which will promote the availability of models and their implementation in other industries. This work demonstrates that once a model infrastructure is available, its implementation in the design and verification of embedded systems for domainspecific applications is viable.
Controller Output/V
2 Simulink Reference Model Specification Model Transaction Level Model Virtual Platform Model
1.5
1
0.5
0
0
10
20
30
40
50 Time/sec
60
70
80
90
100
REFERENCES
System Output/°C
25 20 15 ←Disturbance
10
PID
→
OFF
← PIDON
Simulink Reference Model Specification Model Transaction Level Model Virtual Platform Model
5 0
0
10
20
30
40
50 Time/sec
60
70
80
90
100
Fig. 5. Simulation results of the three SystemC based digital controllers and a Simulink reference model Figure 6 presents the relative temperature differences of the physical plant models controlled by our SystemC based models. The results are presented with respect to a Simulink reference model. Our PID algorithm implementation is different to the one used by Simulink’s PID block. It becomes evident when the PID models start (100-125% peeks between 1-1.1sec that are not shown in the graph) and when they are reseted. An anti-windup PID algorithm implementation could be used to solve this issue. It is also interesting to see that relative differences are bigger for the Virtual Platform Model, which computes the same PID algorithm implementation, however complied with another compiler for a different processor architecture. |Relative Difference|
0.02 Specification Model Transaction Level Model Virtual Platform Model
0.015
0.01
0.005
0
0
10
20
30
40
50 Time/sec
60
70
80
90
100
Fig. 6. Relative output temperature differences with respect to a Simulink reference model 7. CONCLUSIONS AND OUTLOOK Model-based approaches for the design and verification of CPS are a promising solution to understand their complexity, identify and solve potential problems through abstraction, and to enhance the productivity of engineers. They can also help in the transition to implementation solutions through a better understanding of a system and its parts. This paper exposed the challenges involved in the integration of domain specific modeling languages and proposed a possible solution based on Simulink and SystemC. Simulink is already a de facto tool in many industries, thus models are widely available. SystemC models are already available in the commercial and academic domain, but they are specialized for particular applications. There is currently much work being done in the standardization of CESCIT 2012 3-5 April 2012. Würzburg, Germany
Borland, J.F., Thibeault, C., and Zilic, Z. (2005). Using Matlab and Simulink in SystemC verification environment. In Proceedings of Design and Verification Conference, DVCon05. Bouchhima, F., Nicolescu, G., Aboulhamid, E.M., and Abid, M. (2007). Generic discretecontinuous simulation model for accurate validation in heterogeneous systems design. Microelectronics Journal, 38(6-7), 805–815. Cervin, A. and ˚ A rz´en, K.E. (2009). TrueTime: Simulation Tool for Performance Analysis of Real-Time Embedded Systems. In G. Nicolescu and P.J. Mosterman (eds.), Model-Based Design for Embedded Systems. CRC Press. Derler, P., Lee, E.A., and Sangiovanni-Vincentelli, A. (2011). Addressing Modeling Challenges in CyberPhysical Systems. Technical Report UCB/EECS-201117, EECS Department University of California, Berkeley, Berkeley. Eker, J., Janneck, J., Lee, E.A., Liu, J., Liu, X., Ludvig, J., Sachs, S., and Xiong, Y. (2003). Taming heterogeneity the Ptolemy approach. Proceedings of the IEEE, 91(1), 127–144. Gheorghe, L., Nicolescu, G., and Boucheneb, H. (2009). Generic Methodology for the Design of Continuous/Discrete Co-Simulation Tools. In G. Nicolescu and P.J. Mosterman (eds.), Model-Based Design for Embedded Systems. CRC Press. Hylla, K., Oetjens, J.H., and Nebel, W. (2008). Using SystemC for an extended MATLAB/Simulink verification flow. In 2008 Forum on Specification, Verification and Design Languages, 221–226. IEEE. Karsai, G. and Sztipanovits, J. (2008). ModelIntegrated Development of Cyber-Physical Systems. In U. Brinkschulte, T. Givargis, and S. Russo (eds.), Software Technologies for Embedded and Ubiquitous Systems, volume 5287 of Lecture Notes in Computer Science, 46–54. Springer Berlin / Heidelberg. Lee, E.A. (2006). Cyber-Physical Systems -Are Computing Foundations Adequate? In NSF Workshop On Cyber-Physical Systems: Research Motivation, Techniques and Roadmap. Lee, E.A. (2008). Cyber Physical Systems: Design Challenges. In International Symposium on Object/Component/Service-Oriented Real-Time Distributed Computing (ISORC). Mendoza, F., Kollner, C., Becker, J., and MullerGlaser, K.D. (2011). An automated approach to SystemC/Simulink co-simulation. In 2011 22nd IEEE International Symposium on Rapid System Prototyping, 135–141. IEEE. Phillips, C.L. and Harbor, R.D. (1991). Feedback control systems. Prentice Hall, second edi edition. Zeigler, B.P., Praehofer, H., and Kim, T.G. (2000). Theory of modeling and simulation, volume 100. Academic Press New York.
229