Co-modelling and Co-simulation in Embedded Systems Design
The collaborative development of an embedded system requires productive interaction between engineers from very different backgrounds. Control engineering and software engineering have matured over many decades, each with its own philosophy, methods and t
- PDF / 308,926 Bytes
- 11 Pages / 439.36 x 666.15 pts Page_size
- 89 Downloads / 204 Views
Co-modelling and Co-simulation in Embedded Systems Design John Fitzgerald and Kenneth Pierce
2.1 Introduction This chapter introduces the first basic concepts of co-modelling and co-simulation, including notions of system, model and co-model, simulation and co-simulation, etc. It also describes the ways in which co-modelling and co-simulation can be integrated with established development processes such as IEEE 15288 (Systems and Software Engineering—System Life Cycle Processes, [45]) and IEEE 12207 (Systems and Software Engineering—Software Life Cycle Processes, [44]). The collaborative development of an embedded system requires productive interaction between engineers from very different backgrounds. Control engineering and software engineering have matured over many decades, each with its own philosophy, methods and terminology, and so it is necessary to clarify the common ideas that underpin co-modelling and co-simulation. This chapter introduces these concepts, including the ideas of system (Sect. 2.2), model (Sect. 2.3), comodel (Sect. 2.4), co-simulation (Sect. 2.5) and design space exploration (DSE) (Sect. 2.6). Realising collaborative modelling and co-simulation within established development processes is considered in Sect. 2.7. Finally, Sect. 2.8 provides a summary of the chapter.
2.2 Systems and System Boundaries We build models in order to assist in the design of systems. We regard a system as an entity that interacts with other entities, including hardware, software, humans and the physical world [6]. The system may itself be a group of interacting or
J. Fitzgerald () • K. Pierce Newcastle University, Newcastle upon Tyne, UK e-mail: [email protected]; [email protected] J. Fitzgerald et al. (eds.), Collaborative Design for Embedded Systems, DOI 10.1007/978-3-642-54118-6__2, © Springer-Verlag Berlin Heidelberg 2014
15
16
J. Fitzgerald and K. Pierce
interdependent items forming a coherent whole [4]. The system boundary defines a frontier between the system and the entities that form its environment. The developer can exercise some choice over the design of entities within the boundary of a system of interest. By contrast, the laws governing the behaviour exhibited by the environment are beyond the developer’s direct control. In an embedded system, the entities within the system boundary may be digital computing elements or physical elements such as machines. The environment provides stimuli to the system, and the resulting behaviour of the system, visible at its boundary, is termed its response. Embedded control systems are typically thought of as being composed of a controller and plant (“that part of the system which is to be controlled” [43]). The controller contains the control laws and decision logic that affect the plant directly by means of actuators and receive feedback via sensors. Experience suggests that, while control engineers and software engineers might broadly agree on these definitions, they will have a natural bias towards some aspects of a system. Fo
Data Loading...
