Discover millions of ebooks, audiobooks, and so much more with a free trial

From $11.99/month after trial. Cancel anytime.

Design Automation of Cyber-Physical Systems
Design Automation of Cyber-Physical Systems
Design Automation of Cyber-Physical Systems
Ebook599 pages5 hours

Design Automation of Cyber-Physical Systems

Rating: 0 out of 5 stars

()

Read preview

About this ebook

This book presents the state-of-the-art and breakthrough innovations in design automation for cyber-physical systems.The authors discuss various aspects of cyber-physical systems design, including modeling, co-design, optimization, tools, formal methods, validation, verification, and case studies. Coverage includes a survey of the various existing cyber-physical systems functional design methodologies and related tools will provide the reader unique insights into the conceptual design of cyber-physical systems.



        



            

LanguageEnglish
PublisherSpringer
Release dateMay 9, 2019
ISBN9783030130503
Design Automation of Cyber-Physical Systems

Related to Design Automation of Cyber-Physical Systems

Related ebooks

Electrical Engineering & Electronics For You

View More

Related articles

Reviews for Design Automation of Cyber-Physical Systems

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    Design Automation of Cyber-Physical Systems - Mohammad Abdullah Al Faruque

    Part IDesign and Engineering

    © Springer Nature Switzerland AG 2019

    Mohammad Abdullah Al Faruque and Arquimedes Canedo (eds.)Design Automation of Cyber-Physical Systemshttps://doi.org/10.1007/978-3-030-13050-3_1

    1. Concept Design: Modeling and Synthesis from Requirements to Functional Models and Simulation

    Jiang Wan², Nafiul Rashid¹  , Arquimedes Canedo¹ and Mohammad Abdullah Al Faruque¹

    (1)

    University of California, Irvine, Irvine, CA, USA

    (2)

    Siemens Corporate Technology, Princeton, NJ, USA

    Nafiul Rashid

    Email: [email protected]

    1.1 Introduction

    Cyber-physical systems (CPS) are the new generation of automated systems that come with the tight coupling of the cyber and physical world. Examples include automotive systems, smart grids, healthcare monitoring, robotics, etc. Unlike embedded systems, which are generally standalone devices, a complete CPS is a combination of interacting physical components with physical inputs and outputs, forming a network using cyber components [27]. The main advantage of CPS is that it allows different physical components from disparate domains to interact. This flexibility brings new challenges for the design of CPS as it requires the collaboration of multiple domain experts/engineers from different fields. On the other hand, the competition among market peers and time-to-market of the products requires faster design, simulation, development, and deployment of CPS. The only way to meet these requirements is by developing integrated and automated engineering tools. The purpose of these tools is to bring the design requirements of CPS from different domains under one umbrella at the very early design stage.

    1.1.1 Motivation

    One of the most technologically advanced and complex cyber-physical systems currently being produced is Automotive CPS. The traditional method of developing automobiles with completely mechanically driven systems is obsolete nowadays. Modern automobiles are now developed with the marriage of cyber and physically driven systems. The cyber components consist of the networked systems [5] and the software (electronic control units [ECUs]) that controls the physical components. For example, hundreds of cooperating cyber components interacting with the multi-physics physical processes in an automobile contribute to the rapid advances in various areas such as safety, fuel consumption, efficiency, etc. Multiple domain experts from various organizations collaborate to design a modern automobile, which can consist of hundreds of ECUs [1, 13]. It is a challenging task for companies to collaborate to improve the automotive design process. Therefore, it is important to create design automation tools to facilitate multi-disciplinary collaboration [15].

    The objective of developing state-of-the-art automotive design tools is to reduce the critical path [45]. The detailed design phase [7, 22, 41] that includes precise engineering specifications created by the domain experts is called the critical path. Engineers from every domain have their preferred design tools to work with. For example, control engineering is done using LabView [25], LMS [28], Modelica [31], and Matlab/Simulink [39]; electrical engineers use Electronic Design Automation (EDA) design tools; mechanical engineering is supported by Computer-Aided Design (CAD) and Engineering (CAE) tools; and software engineers use UML [30] and in-house software development environments [9]. However, the incompatibility between different domains has made it difficult to combine these tools to perform system-level analysis and simulations [17]. Therefore, model-based systems engineering (MBSE) methodologies and tools [19] have become more popular as they allow high-fidelity multi-disciplinary system-level simulations.

    1.1.2 Functional Modeling

    A functional model decouples the design specifications (functions) of the systems from the behavior and/or architecture and reflects what each system does. Detailed domain-specific knowledge is discouraged in a functional model. Thus, it facilitates collaboration among different disciplines, bringing the domain experts’ minds to the same level of abstraction [45]. The high abstraction level in the functional models makes them a suitable formalism for CPS design. Functional models abstract the details of the continuous and discrete dynamics of CPS and allow cross-domain collaboration [22, 41, 44]. Moreover, functional modeling is a systems engineering activity [18] that allows systems and their subsystems to be described in terms of their respective functionalities. Although functional models are very useful, they may have additional security issues which are not within the scope of this chapter. Various researchers have addressed the inherent security issues in CPS design as a whole [2] and at the functional level [43].

    To adopt the use of functional models as a system engineering practice, the formalization of a functional model [21, 35] is very important. To facilitate that, the Functional Basis language [21, 40] has been successfully implemented for function decomposition in the early design stage [10, 24, 36, 46]. The use of a constrained vocabulary as well as well-defined functions and flow semantics may help establish the functional modeling practice among different designers. Thus, it allows them to rely on the same language to design and analyze systems. As a result, Functional Basis language has become the de-facto standard for functional modeling [34]. Functional Basis defines three flow categories (material, energy, and signal) that expand into a total of 18 flow types, and 8 function categories with a total of 32 primitive functions as presented and discussed in [45]. Although Functional Basis language has been successfully used to provide a common platform of communication among different domain experts, the current major research challenge is making it executable for performing extensive design space exploration. Therefore, generating an executable system-level model from the functional model to perform design space exploration is essential for the adoption of this methodology in industry [45]. The functional model has already been used to synthesize architecture for automotive design [20]. However, this synthesis process is not automatic and does not utilize the functional model to help the design space exploration at the architecture level. Notably, an earlier work [12] has also demonstrated the possibility of using Functional Basis language to enable the early stage design automation for CPS.

    1.1.3 Simulation in CPS

    To design, validate, and test complex systems like CPS, simulation is widely used during the early design stage across industries. Simulations allow the engineers to analyze systems virtually in the cyber domain instead of implementing an actual prototype of these systems in the physical domain. Thus, simulations are quite cost-effective and efficient for the early design stage evaluation of the systems.

    There are many state-of-the-art design automation tools [4, 28] that use various system simulation languages. For example, VHDL-AMS [14], Simscape [38], and Modelica [31] are some of the system simulation languages that allow modeling and simulation of multi-disciplinary systems. However, the lack of early stage design tools causes the simulation models to be generated manually by the domain experts. This manual process is very time consuming and less effective for multi-disciplinary systems as each of the disciplines has their own domain-specific tools and language. Although, SysML [33] is proposed as a domain-independent system-level modeling language [3, 23, 46], it has limitations in terms of expressing and executing those models [6].

    This chapter discusses a novel approach mentioned in [45] for the creation of CPS design tools. Throughout the chapter, we will use automotive CPS and its related terms as an example of CPS. The rest of the chapter is organized as follows: Section 1.2 presents the detailed implementation of a functional model synthesis tool [45] that enables directly selecting architectures and generating high-fidelity multi-disciplinary simulation models from a functional model. Furthermore, Sect. 1.2.1 discusses the feedback function to facilitate the generation of closed loop system-level simulation models, an essential concept for control, software, sensors, and actuators of a CPS. Sections 1.2.2.4 and 1.2.3 present the detailed implementation of the synthesis tool in two separate steps. Section 1.2.2.4 discusses the contextualization-based mapping technique that translates functions to architecture components based on the contextualization of the components and (feedback) flows. Section 1.2.3 discusses the technique to generate the corresponding simulation models from the selected architectures. Section 1.2.4 presents the refinement process used to generate the high-fidelity simulation models. An example evaluation of a CPS use case is presented in Sect. 1.3 to demonstrate the usability of the discussed functional model synthesis tool. Finally, Sect. 1.4 concludes the chapter.

    1.2 Functional Model Synthesis Tool

    The main objective of the functional model synthesis tool is to support the automatic generation of CPS simulation models from the functional models. A functional model is a labeled directed multigraph, where each node is a function in the model and each edge represents the flow from source to target node. On the other hand, a simulation model is a strongly typed component with well-defined CPS ports and connectors that obey the energy conservation principles in various domains and allow components to exchange physical energy and data. The generated simulation models are comparable to the manual selection as done by the experts.

    This chapter capitalizes on the method [45] that exploits the key insights of the two approaches mentioned in [11, 12]. In [11], researchers have developed a context-sensitive mapping technique to synthesize general purpose low-fidelity simulation models without leveraging any domain-specific knowledge. In [12], they have developed a high-level synthesis technique that utilizes the domain-specific knowledge in automotive architectures to generate medium fidelity simulation models. Combining the strength of these two approaches, researchers in [45] developed a novel functional model synthesis tool for synthesizing high-fidelity multi-domain CPS simulation models. The overall design flow of the tool is presented in Fig. 1.1. The feedback function and architecture templates used in the tool provide the basis for an architecture-driven mapping of functions to components. This mapping is further contextualized by the context-sensitive synthesis technique to generate simulations.

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig1_HTML.png

    Fig. 1.1

    The design flow of the functional model synthesis tool [45]

    1.2.1 Feedback Function

    In principle [35], a function is a process applied to an input flow to produce an output flow. That is why most functional models lack feedback information. With the approach mentioned in this chapter, when the functional model is transformed into a system-level simulation model, the synthesis technique applies design rules to create feedback of flows and components with the help of a feedback function as a complementary to the Functional Basis language. Figure 1.2 shows the syntax and semantics of the proposed feedback function. The feedback function has 2 properties: (1) The syntax feeds back a flow produced by a successor function to a predecessor function (a function executed earlier in time relative to a successor); (2) The semantics define the reuse or returning of material, energy, or signal flow to a predecessor function.

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig2_HTML.png

    Fig. 1.2

    Feedback function can be visualized as a flow from a successor to a predecessor function [45]

    1.2.2 Synthesizing Architecture Models

    As shown in Fig. 1.1, once the functional model is ready, the next step is to synthesize it into architecture models. The researchers from electronic design automation refer the architecture-based design also as platform-based design [42]. It allows the collaborative development of complex systems across different organizations [8]. The reusability of components offered by these architectures/platforms saves billions of dollars for the companies annually [16]. The method uses the existing knowledge of architectures to develop the architecture synthesis technique of the functional model synthesis tool. The architecture synthesis method supports the early design stage by synthesizing all the system-level potential architectural solutions that satisfy the design intent depicted by the designer in the functional model.

    An architecture component is a pair of functional model, and a list of constraints that specify relevant architectural parameters and properties such as the number of cylinders in an engine and data path width in an ECU. An architecture template is a multigraph, where each node is an architecture component, and each edge is the connector connecting the source component and target component. Each of the architecture components is associated with a list of constraints that this architecture must meet. An architecture library consists of two sub-libraries, where one sub-library is a collection of architecture components and another is a collection of architecture templates. And user given requirements is a set of requirements expressed in temporal logic that determine the expected system’s characteristics.

    The architecture synthesis technique uses the architecture library, composed by architecture components and templates, to allocate functions to candidate architectures. The functional model created using the Functional Basis language allows the functional model synthesis tool to validate the design contracts [37] because the interfaces are strongly typed and can be mapped to CPS contexts (i.e., electrical, mechanical, signals, etc.) [11]. As a result, the contextualization-based mapping technique is used for mapping functional models to candidate architectures in the following subsections.

    1.2.2.1 Contextualization Based on Input/Output Flows

    In order to reliably generate high-quality simulation models, finding the correct function-to-component mapping for a given functional model is very important. Therefore, every function within the functional model of a CPS must be contextualized by its input and output flows. Two types of flows are defined for every function: primary and secondary. Primary flows are the flows that are inherent to a given function. The primary flows are fixed for every function, and they add no new information to the system. Therefore, for flow-contextualization, secondary flows are necessary. Secondary flows are the non-essential inputs/outputs of a function. Secondary flows reduce the many-to-many function-to-component relation down to a one-to-one mapping.

    1.2.2.2 Contextualization Based on Components

    The system-level components provided by academic and commercial libraries [26, 31, 32] are reusable but are not sufficient for automatic synthesis (which is explained in detail in Sect. 1.2.4.2). Therefore, to automatically generate the correct simulation models, it is very important to define the level of component granularity required by the synthesis techniques. For example, each simulation component (such as Modelica) defines both the structure (i.e., a capacitor) and its dynamic behavior using differential equations. Additionally, a component’s connectors (or ports) specify the equations to honor energy conservation principles. Finally, components have an annotation field that can be used to store information about the component such as its documentation or icon.

    The name-space of the component in a library is used to classify its domain (e.g., Modelica.Electrical.Analog.Basic and Modelica.Mechanics.Components) and to locate the component (e.g., resistor and damper). Since the technique works at the component level, the equations and behaviors associated with the component are never modified. The type of connectors in a component is used to determine the correct physical interface and generate compliant simulation models. Connector types are also useful to generate the energy conservation laws when a feedback function relates various components. A component’s annotation field can be used as the means to associate and store the mappings of components-to-functions. Given the required level of component granularity, this technique imports the functions of a functional model and builds an abstract syntax tree to access a component’s connectors, equations, techniques, and annotations during the mapping process.

    1.2.2.3 Context-Sensitive Mapping of Functions to Components

    Context-sensitive mapping enables the mapping from functions to components. The mapping requires a specific function, a functional model, and a set of potential components to be mapped as input. First, it parses the input components into an abstract syntax tree (AST), where equations, techniques, connectors, and annotations are accessible for the technique. One context tree may be built for each function while mapping the input function to the component (an example of the context tree is shown in Fig. 1.3). Based on the context given by the function’s signature (root node) and the secondary input/output flows (inner nodes), the realization mechanism may be deduced from basic engineering principles and added as the leaf nodes. The context tree may then be traversed (starting at the root) to create a path according to the existing secondary flows and the appropriate realization mechanism. This path may represent the flow-based contextualized function and all the functions and flows in the path may be mapped to the input components, thus may create a set of appropriate mapping. The details of the context-sensitive mapping may be found in [45] along with the pseudo code of the mapping technique.

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig3_HTML.png

    Fig. 1.3

    A context tree for the Convert function of the automotive system

    1.2.2.4 Function to Architecture Synthesis

    With the help of the context-sensitive mapping technique, the high-level synthesis technique may be developed for synthesizing functional model to architectural models. Given a functional model and the user-defined requirements as inputs, the objective of the function to architecture synthesis technique is to find the set of architecture templates in architecture library that fully or partially map to the functional model.

    The function to architecture synthesis technique will generate both full and partial mappings from a functional model into a set of architecture templates based on the knowledge contained in the architecture library. The synthesis technique may also provide top-down and bottom-up refinements as design suggestions for functional model and architecture templates. The synthesis technique may perform a branch and bound synthesis [29] as follows: First, it can prune the selection of architecture templates whose constraints do not meet the requirements. Based on the selected architecture templates, it will aggregate the maximum possible mapping from functional model to architecture templates using the context-sensitive mapping technique.

    After the architecture template design space has been expanded, the synthesis technique will perform a multi-step pruning process on each architecture template. Once the pruning is done, the synthesis technique will refine all partial mappings in a top-down manner. And the bottom-up refinement can be done on the functions that exist on the selected architecture templates but not in the functional model. The details of the refinement process are presented in Sect. 1.2.4. The refinement suggestions can help the designers to increase the fidelity of the original functional model. The details of the function to architecture synthesis technique can be found in [45] along with the pseudo code.

    1.2.3 Architecture to Simulation Model Synthesis

    Once the candidate architectures have been identified from the functional models using the function to architecture synthesis technique, the next step is to generate the corresponding simulation models.

    The architecture to simulation model synthesis technique will generate simulation models for all the architecture-mapped functional models identified by the function to architecture synthesis technique. First, it will broaden the simulation design space for each of the architecture templates generated in Sect. 1.2.2.4. Whenever an architecture-mapped function cannot be mapped to any simulation component, a top-down refinement of simulation models may be constructed (see details of the refinement process in Sect. 1.2.4). Then, it will expand the simulation design space by creating individual simulation models for all possible combinations of simulation components that match an architecture-mapped functional model. Finally, it will add connections to every model according to the topology in their corresponding architecture component. Interested readers may refer to [45] for the details of the synthesis technique.

    1.2.4 Process of Refinement

    Designing CPS is a complex process that involves multiple iterations. For example, in automotive CPS one design is refined multiple times by multiple personnel from various organizations. The synthesis technique presented in this chapter supports the refinement of the low-fidelity functional models to achieve high fidelity. For example, after the initial candidate architectures have been identified, the architecture models may contain a set of functions that are not modeled in the original functional model. Thus, a refined functional model can be created by back-propagating this architecture information to the functional model. This refinement is referred to as bottom-up refinement as information is being propagated from a lower level of abstraction (architecture) to a higher level of abstraction (functions) to achieve high fidelity. The level of fidelity is the amount of qualitative and quantitative information that can be obtained from a model. On the other hand, incompleteness of a model is the lack of fidelity necessary to answer a specific engineering question. And, refinement is the process by which the level of fidelity of a model is increased to make it less incomplete, and thus the ability to answer more detailed engineering questions.

    1.2.4.1 Top-down Refinement Process

    As the name implies, a top-down refinement increases the level of fidelity by propagating the information from a higher level of abstraction (functions) to a lower level of abstraction (architecture). For example, sometimes a functional model contains a set of functions that are not fulfilled by any of the components in the architecture library. To satisfy those functional requirements of that particular functional model, a new architecture component with the relative complement of the functions is created by the new architecture component in the architecture library.

    1.2.4.2 Bottom-up Refinement Process

    The bottom-up refinement analyzes the ports and interface of a simulation component to determine the functions automatically. In addition to that, the flow (energy, material, and signals) transformations occurring within the component’s internal structure is also determined. Using the functions performed by the simulation components, the bottom-up step classifies the components in a library. Thus, it helps to achieve a correlation between functions, architectures, and simulation components that design tools may use to synthesize simulation models for candidate system architectures.

    The type of energy, material, or signals that one component exchanges with another through its ports can be obtained using the components’ interface analysis. The interface analysis infers the functions achieved by a given simulation component as shown in Fig. 1.4. For example, the Electric Motor component has three ports: thermal, electrical, and rotational mechanical energy. Typically, conjugate variables that represent effort/flow are used to exchange energy between the simulation components. Electrical energy, rotational mechanical energy, and thermal energy are represented by the conjugate variables’ voltage/current, torque/angular velocity, and temperature/heat flow, respectively. As the relationship between the functional level and simulation component level energy is known, the technique determines that the Electric Motor is able to perform the function of "Convert" energy from any port to the other ports. This leads to six inferred functions.

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig4_HTML.png

    Fig. 1.4

    Extraction of functions from simulation components [45]

    Sometimes, this technique also performs a structural analysis—a hierarchical traversal and flattening—of the internal simulation component structure to expose all the domains (e.g., electrical, mechanical, thermal, signals, etc.) that are not visible through the interface of the simulation components. Figure 1.5 shows how structural analysis helps to expose all the domains revealing the invisible functions. Interested readers can refer to [45] to know the details about the structural analysis.

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig5_HTML.png

    Fig. 1.5

    Structural analysis on simulation components reveals additional domains and the energy, material, and signal transformations between them [45]

    1.3 Evaluation of Functional Model Synthesis Tool

    This section presents a real-world automotive case study as introduced in [45]. The case study demonstrates the effectiveness of functional model synthesis tool to synthesize the multi-domain simulation model using the cyber-physical aspects of a functional model. The tool generates the simulation models automatically using the existing architecture knowledge after evaluating different candidate architectures of designing an engine system. It also demonstrates how the feedback function and the refinement process help to generate the high-fidelity multi-domain simulation models.

    1.3.1 Architecture Model Synthesis

    Figure 1.6 represents the functional model of the engine system. Using the architectural templates shown in Fig. 1.7, the functions (blocks) and flows (arrows) can be naturally mapped to the main subsystems of an automotive system . For example, the function "convert chem. energy to rot. mech. energy" can be mapped to an Engine ICE, Series Hybrid, and Parallel Hybrid architectures.

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig6_HTML.png

    Fig. 1.6

    An example functional model of an automotive power-train, associated requirements, and architectural constraints [45]

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig7_HTML.png

    Fig. 1.7

    Architecture templates for the engine block [45]

    Table 1.1 shows the user-defined requirements and Table 1.2 shows the constraints for five automotive architecture templates. The function to architecture synthesis technique in Sect. 1.2.2.4 eliminates the third constraint of minimum price (Electric Fuel Cell) from the architectural design space as it violates user-defined requirements maximum price. Furthermore, the synthesis technique also eliminates the Electric architecture template because neither "Store EE nor Convert EE to RME" functions exist in the functional model. It is to note that the ICE architecture template fully matches the functional model, whereas the Series Hybrid and Parallel Hybrid templates partially match the functional model.

    Table 1.1

    User-defined requirements

    Table 1.2

    Constrain list of architecture templates

    a EFC electric fuel cell

    1.3.2 Simulation Model Synthesis

    Functional models support the technology-independent design requirements. Moreover, the functional model synthesis tool uses the design requirements to facilitate the automatic generation of simulation models for different architectures that satisfy those design requirements. For example, a software engineer may create a functional model to design the engine control system (ECU and its control software) represented by the "Sense and the Control" functions as shown in Fig. 1.6. However, the software engineer might be able to do so with a very minimal knowledge of mechanical engineering.

    1.3.3 Feedback Function’s Usability

    The two feedback functions shown in Fig. 1.6 are used as an additional support to the Functional Basis language [45]. Researchers in [45] designed a functional model of an engine system using only Functional Basis language and without the feedback function. The intention is to demonstrate the usability of the feedback functions. Then that functional model is synthesized using the functional model synthesis tool to generate the simulation models for the ICE architecture. Simulation models are synthesized from both functional models (with feedback and without feedback function) and their performances are compared. The fuel consumption is much less with feedback functions compared to the one without feedback functions as shown in Fig. 1.8. Furthermore, Fig. 1.9 demonstrates that engine models synthesized with feedback functions generate much less emissions (CO, NOx, and HC) as compared to the ones without the feedback functions. The reason is, the feedback functions are mapped to additional control units which cause more efficient use of the engine.

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig8_HTML.png

    Fig. 1.8

    Comparison of the fuel consumption between the synthesized simulation models with/without Feedback [45]

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig9_HTML.png

    Fig. 1.9

    Comparison of emissions between the simulation models with/without Feedback [45]

    1.3.4 Refinement Process Analysis

    The usefulness of the bottom-up refinement of the discussed methodology is illustrated in Fig. 1.10. As shown in Fig. 1.6, original functional model does not have the functions "Convert RME to EE, Convert EE to RME, and Store EE." However, the function to architecture synthesis technique in Sect. 1.2.2.4 generates the partial mappings to architectures (ICE, Hybrid, and Electric) and system engineers get the refined functional models suggestions. For example, new functions such as "Convert RME to EE, Store EE, and Convert EE to RME" are created using the Hybrid architecture mapping. The number of functions in the refined functional models generated from three different mappings is presented in Fig. 1.11.

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig10_HTML.png

    Fig. 1.10

    Bottom-up refinement of a functional model [45]

    ../images/462058_1_En_1_Chapter/462058_1_En_1_Fig11_HTML.png

    Fig. 1.11

    Number of functions in the refined functional models [45]

    1.4 Conclusion

    This chapter discusses the role of functional models in the design and development of CPS. It starts by creating the functional model from design requirements. Moreover, the chapter emphasizes the design automation techniques that automatically generate high-fidelity multi-domain simulation models from the functional model. The functional model synthesis tool [45] as discussed in this chapter takes the advantage of existing architectures’ knowledge to develop other candidate, architecture-specific simulation models for complex CPS and facilitates early design space exploration. For the detailed implementation of the tool, the concept of a Feedback function [45] is also discussed to capture feedback flows that are essential for complex systems using control, software, sensors, and actuators. A context-sensitive mapping technique is also discussed to construct an appropriate engineering context that facilitates the selection of function-to-component mappings by considering the surrounding flows of a function. Moreover, a refinement process is also discussed that backpropagates the results as design suggestions to the system-level designers. Finally, the usability of the discussed functional model synthesis tool is presented using an automotive engine system.

    References

    1.

    Abelein, U., Lochner, H., Hahn, D., & Straube, S. (2012, March). Complexity, quality and robustness-the challenges of tomorrow’s automotive electronics. In Design, Automation & Test in Europe Conference & Exhibition (DATE), 2012 (pp. 870–871). Piscataway: IEEE.

    2.

    Al Faruque, M., Regazzoni, F., & Pajic, M. (2015, October). Design methodologies for securing cyber-physical systems. In Proceedings of the 10th International Conference on Hardware/Software Codesign and System Synthesis (pp. 30–36). New York: IEEE Press.

    3.

    Alvarez Cabrera, A. A., Erden, M. S., & Tomiyama, T. (2009). On the potential of function-behavior-state (FBS) methodology for the integration of modeling tools. In Proceedings of the 19th CIRP Design Conference Competitive Design. Bedford: Cranfield University Press.

    4.

    ANSYS Tool Kits for Automotive Solutions. http://​www.​ansys.​com/​Industries/​Automotive/​

    5.

    AUTOSAR Automotive Open System Architecture. https://​www.​autosar.​org/​

    6.

    Bassi, L., Secchi, C., Bonfe, M., & Fantuzzi, C. (2011). A SysML-based methodology for manufacturing machinery modeling and design. IEEE/ASME Transactions on Mechatronics, 16(6), 1049–1062.Crossref

    7.

    Boucher, M., & Houlihan, D. (2008). System design: New product development for mechatronics. Boston: Aberdeen Group.

    8.

    Broy, M., Gleirscher, M., Kluge, P., Krenzer, W., Merenda, S., & Wild, D. (2009). Automotive architecture framework: Towards a holistic and standardised system architecture description. White paper. IBM Corporation. Technical Report, Technische Universitt Mnchen. TUM-I0915.

    9.

    Broy, M., Kruger, I. H., Pretschner, A., & Salzmann, C. (2007). Engineering automotive software. Proceedings of the IEEE, 95(2), 356–373.Crossref

    10.

    Bryant, C. R., Stone, R. B., McAdams, D. A., Kurtoglu, T., & Campbell, M. I. (2005). Concept generation from the functional basis of design. In ICED 05: 15th International Conference on Engineering Design: Engineering Design and the Global Economy (p. 1702). Barton: Engineers Australia.

    11.

    Canedo, A., Schwarzenbach, E., & Al Faruque, M. A. (2013, April). Context-sensitive synthesis of executable functional models of cyber-physical systems. In Proceedings of the ACM/IEEE 4th International Conference on Cyber-Physical Systems (pp. 99–108). New York: ACM.Crossref

    12.

    Canedo, A., Wan, J., & Al Faruque, M. A. (2014, November). Functional modeling compiler for system-level design of automotive cyber-physical systems. In 2014 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), (pp. 39–46). Piscataway: IEEE.Crossref

    13.

    Charette, R. N. (2009). This car runs on code. IEEE Spectrum, 46(3), 3.MathSciNet

    14.

    Christen, E., & Bakalar, K. (1999). VHDL-AMS-a hardware description language for analog and mixed-signal applications. IEEE Transactions on Circuits and Systems II: Analog and Digital Signal Processing, 46(10), 1263–1272.Crossref

    15.

    Cooprider, A. (2014). Automotive embedded systems tutorial-part I. In Proceedings of the 51th Design Automation Conference, DAC (Vol. 2014).

    16.

    Dahmus, J. B., Gonzalez-Zugasti, J. P., & Otto, K. N. (2001). Modular product architecture. Design Studies, 22(5), 409–424.Crossref

    17.

    Derler, P., Lee, E. A., & Vincentelli, A. S. (2012). Modeling cyberphysical systems. Proceedings of the IEEE, 100(1), 13–28.Crossref

    18.

    Erden, M. S., Komoto, H., van Beek, T. J., D’Amelio, V., Echavarria, E., & Tomiyama, T. (2008). A review of function modeling: Approaches and applications. Ai Edam, 22(2), 147–169.

    19.

    Fortney, G. (2014, August). Model based systems engineering using validated executable specifications as an enabler for cost and risk reduction. In Proceedings of the 2014 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS).

    20.

    Helms, B., & Shea, K. (2012). Computational synthesis of product architectures based on object-oriented graph grammars. Journal of Mechanical Design, 134(2), 021008.Crossref

    21.

    Hirtz, J., Stone, R. B., McAdams, D. A., Szykman, S., &

    Enjoying the preview?
    Page 1 of 1