Abstract. Introduction

Transcription

1 New Approach of Tools Application for Systems Engineering in Automotive Software Development Celso Mendes 1, Taysa Banik 1, Felipe Franco 1, João Henrique Neme 1, Max Mauro Santos 1, Wanderley Prado 2, Fernando Cerri 2, Vinicius Antunes 2, Lauro Nunes 3 1 UTFPR-PG, 2 OpenCadd Advanced Technology, 3 Marcopolo S.A. Abstract This paper outlines the modeling process in Systems Modeling Language (SysML) in context of Model-Based System Engineering (MBSE) as well as the Model-Based Design (MBD) in Simulink and we compare the models to get useful information into software. For this goal, we propose the use of a Requirements Management and Systems Modeling (RM/SM) tool (3SL Cradle) and development tool (MathWokrs MATLAB/Simulink) to model the system, to do the verifications and validations and finally to embed the generated code. For automotive systems, the development process is visualized through the V-Model, which leads to the right choice of components, the integration of the system and the project realization. The first step in V-Model handles the requirements engineering for the development, i.e., the requirements for a project will be collected in respect to the stakeholder s needs and system limitations and after its analysis system requirements is detailed. Then, the next steps consist of modeling the system based on its requirements, going through simulation, system verification and validation through Model-In-the- Loop (MIL), Software-In-the-Loop (SIL), Processor-In-the-Loop (PIL), and Hardware-In-the-Loop (HIL) tests, and finally harness tests in real applications. In this paper, the chosen modeling language is SysML for the MBSE point of view because it aims to standardize system modeling, by unifying diverse modeling notations used by engineers. This language also supports specification, analysis, design, verification, and validation of systems. To get executable models, we use MATLAB/Simulink models which is largely used by the Original Equipment Manufacturers (OEMs) to develop new products MBSE is a methodology in which complex systems can be modeled. However, it does not generate executable models, i.e., no system simulation occurs from a SysML model. For executable models, there is the MBD approach. MBD is a methodology that can lead to reduced costs of OEM s new products, since it can predict project errors and weaknesses. If the model is running as expected and providing good results, it is possible to go to a next step and implement the project in real applications, in order to observe the behavior of the new product, for example, by embedding software codes directly into hardware or building a new hardware. Due to the complexity of integration of new electrical and electronic systems, MBSE s and MBD s use is justified. Our approach addresses the V-Model through MBSE in SysML and MBD in MATLAB/Simulink towards software verification and validation. To achieve that, we use the commercial RM/SM tool that is used to develop user requirements to system requirements. It provides a SysML design section as well where SysML models can Page 1 of 8 be developed according to system requirements. One of the objectives in using the commercial tool is that it will be possible to analyze the transition from models in RM/SM tools to models for simulation, such as Simulink and offer a new possibility for OEM s and suppliers to abstract system models into executable models. Introduction New products or new releases, versions, and adaptations of a product are designed with the costumers desires which are turned later into system requirements. After those phases, the development starts with the engineering teams. It means that it is necessary to have a link among customers desires, system requirements and the development teams. The system engineering provides this link that manages requirements and provides functional models to development engineering. In this paper, we outline this development process and describe the integration of a new subsystem into a system. Our final target is a new software for a vehicle Electronic Control Unit (ECU). Towards this, we manage requirements and model the subsystem in SysML using Cradle, translate the SysML models into MATLAB/Simulink models, do system tests such as MIL, SIL, PIL and HIL. In order to show the approach for software development, a Mobile Seat Platform (MSP) for coach buses is chosen. MSP is a new subsystem required by the Brazilian Legislation to be part of the bus body [1]. However, the development process for heavy duty vehicles does not follow a standardized manufacturing approach in the whole world [1], i.e., trucks and buses might have several differences regarding the production process worldwide although the functionalities remain the same worldwide. We try to develop a standardized development approach for coach bus systems adaptations. It is quite interesting to model an integration process for coach bus systems once it can be used in several countries. So, other buses manufactures may apply the same models for their own production. This paper is divided into seven main sections, where: the first section gives an overview on Requirements Engineering, MBSE, MBD, SysML and Tests, in the second section the Case MSP is described, the third section presents V-Model of the MSP software development, the section four presents Requirements Engineering of the MSP, the MBSE in SysML models is presented in section five, in the section six the Simulink models are developed and related to SysML Models. Finally, in the section seven the summary and conclusions are presented. A. Requirements Engineering

2 As mentioned before, requirements engineering is one of the most important phases in a project because it collects stakeholders needs as well as stakeholders requirements and translates them into system requirements that provides information used by design and development engineering teams. It is important to handle needs and requirements because it might influence on the project success since stakeholders needs are traceable in the entire development process. In addition, it is possible to generate test cases for the final project stages taking requirements as start-point. A simple example of a test case generated from a requirement is explained as follows: 1. Let s consider the following requirement: the automobile motor shall start when ignition is on. 2. Then, a derived test case would be: let ignition in on mode and see the motor s behavior. 3. If the motor starts regardless of the ignition status, there may be a project error in the phase related to the requirements engineering or system modeling. Formally, requirements are attributes or something which are discovered before building products [2]. In this work, it is showed the project steps towards validation tests going through requirements engineering, system modeling, verification and validation. B. Model-Based Systems Engineering With the increasing number of complex systems and subsystems in commercial vehicles as well as automobiles, it is no longer ideal to wait until a new product is constructed to analyze its behavior. In order to make the process easier and cheaper, Model- Based Systems Engineering and Model-Based Design are used, since project errors can be previewed and corrected in time. For example, when a new E/E architecture for a vehicle has to be applied, it is necessary to consider the fact that a vehicle may have up to 70 Electronic Control Units (ECUs) (luxury class) [1] and the integration between the car s ECUs is complicated. Thus, it increases the complexity of new solutions in E/E architecture and it is very important to have useful information about the architecture to plain better where to act in order to solve an E/E architecture problems. MBSE is a methodology to model complex systems in a graphical way. The advantage to spend time modeling complex systems is that once the system is modeled there may be no great changes in its behavior or activities and any modification can be easily incorporated into the model because it has complete traceability backward system requirements providing impact analysis easily by the project. Therefore, it is simple to verify which subsystems will be affected by any modification on the original models. For example, a car has to run, it has to transport passengers, and it has also to light in some situations, and so on. If a new lighting system is introduced into the car, there is no need to remodel the entire system because the car still running, lightning, and carrying people. It is only necessary to modify the way the car will light (for example, with a new lamp or lightning software). The behaviors have not several changes and any modification in the project may be an adaptation in the original one. Therefore, there are commercial tools like the 3SL Cradle and IBM Doors which provide requirements management and system design what enforces the advantage of using MBSE. Hence, for earliest design, computer modeling is increasingly used [4]. In this manner, MBSE is a very helpful methodology which transmits information among engineers even throughout the years. However, MBSE does not necessarily provide executable models. Then, there is the MBD approach where the systems engineers together with the software engineers can produce executable models. One of the most used MBD tool is the MATLAB/Simulink because it supports a large number of systems as in [3], [5], and [10] in many different knowledge fields as aeronautical and aerospace, automotive, defense, manufacturing, nuclear, process control, telecommunications, and transport. C. System Modeling Language System engineers may have many possibilities for modeling a system and it is done according to a language which translates requirements, specifications, architecture and behaviors into something easier to be understand. The main problem is that it maybe leads to very specific models with very specific languages that are just understandable for the engineer who made it. Thinking in the standardization in MBSE, SysML is a general propose language which accomplishes the most of the existent modeling languages [9]. To achieve that, SysML is defined within three main groups: Structure Diagram Types, Behavior Diagram Types, and Other Diagram Types. These are subdivided into nine diagram types as follows. Structure Diagram Types: Block Definition Diagram (bdd) and Internal Block Definition Diagram (ibd) Behavior Diagram Types: Activity Diagram (act), State Machine Diagram (stm), and Sequence Diagram (sd) Other Diagram Types: Use Case Diagram (uc), Requirement Diagram (req), Parametric Diagram, Package Diagram Every type of diagram represents different information from the system. For example, Structure Diagrams show how the system is built, the systems that are interacting with it, and the external influence on the system. Behavior Diagrams represent the interaction between the systems parts therefore Behavior Diagrams are the most similar SysML models to Simulink models. Other Diagrams represent diverse information as interaction with external systems and actuators, requirements management and so on. Thus, SysML diagrams are used to model concepts [10]. D. Model-based Design and PIL, SIL, and HIL Tests Model-Based Design is mathematical and visual modeling method to design complex systems [3]. MBD becomes important in the development process of many engineering applications as automotive, aerospace, motion control, industrial equipment applications because it decreases costs of mounting physical models to do tests and see the project results. Furthermore, vehicles production is nowadays developed with the partnership between carmakers and suppliers. In this sense, MBSE and MBD might make the OEMs and suppliers communication easier. The main advantage of MBD is the prediction of project errors before constructing physical parts or embedding software [3]. To reach this reliability, MBD provides the following tests: MIL, SIL, PIL, and HIL. Each one is explained as follows: Page 2 of 8

3 MIL (Model-in-the-Loop): stage to collect requirements and trace functional blocks; SIL (Software-in-the-Loop): stage to generate C/C++ codes from the functional models in order to embed it later into the controller. For MBD, it may be done by automatic code generators such as Embedded Coder; PIL (Processor-in-the-Loop): at this stage, the generated code is embedded into the desired controller. PIL tests are characterized by the interaction between the controller with the generated code and virtual models (such as virtual ECUs). Then, the processors performance can be evaluated (memory usage, computation time, run time, etc.) HIL (Hardware-in-the-Loop): At HIL stage, the controller with the embedded code interacts with the physical plant. The, it is the very last stage of MBD where one may see the performance of the controller and of the code during real applications. These MBD tests are validated through MATLAB/Simulink since it covers the whole MBD process. The Subsystem under Consideration: Mobile Seat Platform The Mobile Seat Platform (MSP) is an elevator that aims to lift passengers with disabilities to their seat places in coach busses. Its implementation in coach is required by the Brazilian Legislation in order to improve accessibility for bus passengers. The platform is constituted of an elevator which has a seat to lift the passenger up to the bus. Figure 1 gives an overview on the system under consideration. Figure 2: V-Model for MSP Software Development. According to the V-Model, the costumer s are identified at first stage to detailing the concept of the project going to system requirements using Requirements Engineering languages. Next stages are MBSE modeling the system using SysML and MBD modeling the system software using MATLAB/Simulink. In the MBSE point of view SysML Modeling is more abstract than MATLAB/Simulink Modeling so there are two distinct layers on MBSE process for these modeling notations. MATLAB/Simulink languages are more specific and detailed than SysML. In the other side of V-Model there are the software tests in order to do verification and validation of the developed software using MIL, SIL, PIL and HIL methods. Stakeholder s Needs and Requirements Engineering for the MSP For the MSP Stakeholder s Needs are collected from [1] as follows: a) Security status signals Figure 1: The MSP overview. Taken from [1] In this work, the MSP will be characterized as subsystem of the entire bus since a new functionality is being added to an existing system (in this case, the bus itself). V-Model for the MSP Software Development The V-Model for project development is visualized in figure 1. Body ECU command: it is an authorization for movement, sent through a CAN J1939 message. The conditions for a permission are described in the further up; Seat reclined sensor: a micro-switch sensor, that transmits an analog GND signal when the seat is reclined, avoiding platform movement; Feet protection sensor: a reed-switch sensor, which will pass a GND signal when a mechanic feet-protection for the passenger is correctly armed; Lever sensor: a micro-switch that triggers GND when a manual operation is required (like an electrical failure event). b) Platform position and control Up and Down buttons: there s a manual wired control box, with two buttons, for platform movement; Onboard sensor: a micro-switch sensor that is GNDtriggered when the platform is onboard; Platform over ground sensor: a micro-switch sensor that is GND-triggered when the platform reaches ground, or another obstacle under the platform. c) Measured control signals Page 3 of 8

4 Current sensor signal: a hardware shunt-based measurement of current establishes the maximum value allowed for the motor. If the limit (about 50A) is reached, the platform is blocked; An ADC voltage measurement is performed, in order to check if the power voltage level is low. If it is low, the platform is blocked After the needs are collected, it is useful to translate the stakeholders needs into requirements because stakeholders language might be superficial and confused. Towards this, a good RM/SM Tool is desired since it gives a lot of advantages as management, traceability, structured workflow, and so on. For this work, the 3SL Cradle is chosen because it is one of the best RM/SM Tools in the market and provides SysML for requirements analysis and system design sections. The requirements are shown in figure 3 Figure 4: Context Diagram for the MSP System Hierarchical Structure (SHS), because it is possible to visualize how the new product is affecting the existent system. The System Hierarchical Structure for coach busses will show the subsystems which will be affected by the MSP introduction. Figure 5 show the structures that are affected by the insertion of MSP. Figure 3: Requirements Listing on 3SL Cradle Model-Based Systems Engineering for the MSP For good practices of system modeling, it is recommended that modeling is started with the most abstract diagrams types. Thus, a system is seen as a black box which will be opened according to the other specifications. The main advantage of this approach for modeling is that any change on the project or on the product version will not affect the entire system, since changes may occur in very specific parts of a system and it may do not change the interaction between system and actuators. In this paper, it is wanted to describe the introduction of a new device in a well-known system (coach bus). Thus, a good start-point for modeling is a context diagram where the all relevant external systems can be defined [11]. These external systems may come into account when the control software for the system under consideration is developed. Figure 5: System Hierarchical Structure of Affected Subsystems and New Subsystems Highlighted. From figure 5, it is known that the MSP will influence on the bus body as well as on the electrical assembly because it is mandatory to embed the controller for the platform into the body s ECU. The Use Case Diagram could be the next step to model the system, once in the beginning of the project it is only know the system operation and system interaction with actuators (How should the system behave when an actuator is giving an order?). This type of diagram can be used to requirements analysis also. Figure 6 shows the Use Case for MSP of this paper. One may notice that there are three external actuators: the bus driver, the passenger and the bus Engine. The driver will set the lift up or down by bottoms according to the passenger needs. The passenger is the one who will be transported by the Lift. The Bus Engine is as important as the other two actuators because it will not allow that the device is activated during bus driving. The important information extracted from here is what signals and parameters we should expect to work with in order to make the lift work. Now, we can go forth towards more detailed information with the next type of diagram. Page 4 of 8

5 Figure 6: Use Case Diagram for MSP Since the behavior, the actors, and the structure of the system are defined, it is quite interesting to observe the connections and flows to the MSP ECU which is the target for the new software. Figure 7 is an Internal Block Diagram which represents connections and flows from/to the ECU of subsystem under consideration. Then, the MSP subsystem can have its inputs and outputs well specified. In the figure 7 we see that the ECU is receiving signals from the Body ECU, from the remote control operated by the driver, and from the sensors. These are important information for the next stage of the development in MATLAB/Simulink, as it will be seen. Figure 8: Activity Diagram to the MSP Model-Based Design for MSP Since the SysML models are made, the aim is to abstract information from them into Simulink models that are executable and will give simulated results and may be later embedded into the MSP ECU in order to control the platform. As in SysML, modeling in Simulink starts with blocks that are more general and go towards more specific blocks. For example, in figure 9, one may see the MSP ECU as a black box with inputs and outputs, but no functions. Functions will be developed according to the level of abstraction of the model. The less abstract, the more specific are the functions. For comparison, figure 8 may be developed according to figure 7. Figure 9: MSP ECU Simulink Model. From [1] Figure 7: Internal Block Diagram for the MSP ECU We notice that figure 8 is giving more detailed information regarding the subsystem itself than the other two previous diagrams. For example, it is clear now that the control commands coming from the ECU to the MSD are transported via CAN messages, the bus driver is operating the system, the sensors are providing usual information, and so on. It let us know that an implementation with CAN messages will be necessary in the development process, for example. In addition, it is also clear how the bus driver influences the MSP by operating the remote control of the subsystem. One may observe that it turning in each modeling step that the models are going towards behavior diagrams which are the diagrams that help the systems engineers as well as the software engineers to develop software to embed into the ECU in order to operate the new subsystem being added to the system functions. Inside the black box from figure 9, there are some specific functions. One of them is the error state indicator as visualized in figure 10. Figure 10 shows the Platform Conditions Chart that will check errors in the values of motor current and voltage. If the current or the voltage values in the circuit is too low or too high, it indicates error active and won t let the platform s motor run. If one may compare, it could be linked as a lower level of to the Activity Diagram SysML model in figure 8. Page 5 of 8

6 Figure 10: Platform Conditions Chart. Taken from [1] As an example, one may visualize the State Machine Diagram for Current Error in the circuit (figure 11). Depending on the current value, a failure signal is released and it won t allow the platform to move. Figure 13: State Machine for the Platform Control chart [1] Figure 14 also shows a PWM Control. The difference between figures 14 and 12 is the fact that in figure 14 the adjustment period and the temporization is considered in order to have a soft-start logic [1]. Figure 11: State Machine Diagram for Current Failure in Simulink. From [1] Figure 12 represents the control for the platform. It activates the PWM block in order to start the motor. It checks the errors status as well as other parameters as the platform button position. Figure 14: PWM Control with Time Constraints The State Machine in figure 15 represents the PWM states. It represents the decision that the algorithm should do according to the subsystem inputs. Figure 12: Platform Control Chart. From [1] The State Machine for the blocks in figure 12 is shown in figure 13. The states are as follows: 1. If Button_down is active and the switch-sensor in the ground is open, then the platform moves downwards. 2. If Button_Up is active and onboard sensor is opened, then the platform moves up. 3. If neither states are true, the motor won t be activated. Figure 15: States for the PWM Activation [1] Finally, figure 16 shows the message sent by the Body ECU in order to allow or not the Platform to move (according to Vehicle Speed and Motor Speed Signals). Page 6 of 8

7 Figure 16: Body ECU of the Bus Next steps after modeling the MSP is do functional tests using this virtual prototype verifying and validating these functional models backward to system requirements and SysML Models following the steps below. 1. MIL Model-in-the-Loop: Verifies units functions and consistency cross-checking with SysML models and system requirements; 2. SIL Software-in-the-Loop: Verifies software codes generated automatically using the same criteria of MIL test; 3. PIL Processor-in-the-Loop: Embedding generated code into a development kit interacting to a virtual environment model to verify subsystem integration, functionalities, controller performance and so on; 4. HIL Hardware-in-the-Loop: Embedding the models into a real-time hardware tests can be performed interacting to the real environment and logging the test results it s possible to validate the subsystem cross-checking with all requirements related to the embedded software development of the project. Summary/Conclusions The goal of this paper is to show the MBSE and MBD which are visualized through the V-Lifecycle in the automobile industry. To do that, a case study was developed where one visualizes the integration of a subsystem into a system. Towards the objective, the paper started by the very first stage of the V-Lifecycle (Project Concepts and Requirements Engineering) and goes up to the software tests where executable models may give results that will be important in the next stages in the V-Model, i.e., if the MIL tests give worse results, then the development should be reconsidered before moving to the next stages. Some preliminar results were presented in order to validate the paper s approach. As conclusion, one may realize that the MBSE and MBD approach can be visualized together for better project workflow of the engineer teams as well as for better project management by the stakeholders. It guarantees that project errors might be easier realized and corrected as well as project traceability can be assured. References 1. Nunes, L. R., da Rosa, J. N. H., Banik, T. M., Neme, J. H., Franco, F. R. and Santos, M. M. D., "Design of a Embedded Software Controller for a Mobile Seat Platform for Commercial Vehicle," IEEE Induscon Paper , Pandey, D., Ramani, A. K., and Suman, U., "An Effective Requirement Engineering Process Model for Software Development and Requirements Management," IEEE ARTCom , 2010, doi: /ARTCom Neme, J. H., Santos, M. M. D. and Teixeira, E. L. S., "Model Based Design for Automobile External Lighting Systems," SAE Technical Paper , 2015, doi: / Lamm, J. G. and Weilkiens, T., "Functional Architectures in SysML," Gesellschaft fuer Systems Engineering. Tag des Systems Engineering: , Cortese, D., Efficient CAN Protocol Development Process, SAE Technical Paper , 2009, doi: / Pearce, P. and Friedenthal, S., A Practical Approach For Modelling Submarine Subsystem Architecture In SysML Submarine Institute of Australia Science, Technology & Engineering Conference 2013, Heiming, B. and Haupt, H., Hardware-in-the-Loop Testing of Networked Electronics at Ford, SAE Technical Paper , 2005, doi: / Köhl, S. and Jegminat, D., How to Do Hardware-in-the-Loop Simulation Right, SAE Technical Paper , 2005, doi: / OMG Systems Modeling Language (OMG SysML ) Specification SysML Tutorial. 3SL. 11. Baker, L., Executives Will Want to use MBSE, White paper. Systtems Engineering Conference, Washington DC, Contact Information Celso Luiz Mendes da Silva, undergraduate student at Federal University of Technology Paraná. Monteiro Lobato Av. s/n. Zip: celsosilva@alunos.utfpr.edu.br LinkedIn: Prof. Max Mauro Dias Santos, Adjunct Professor, Universidade Tecnológica Federal do Paraná Ponta Grossa UTFPR-PG Work phone: maxsantos@utfpr.edu.br Acknowledgments The authors would like to thank the OPENCADD Advanced Technology and the Marcopolo S.A. for supporting the whole research process. Definitions/Abbreviations SysML MBSE MBD RM/SM Systems Modeling Language Model-Based Systems Engineering Model-Based Design Requirements Management Page 7 of 8

8 and Systems Modeling BDD Block Definition Diagram MSP Mobile Seat Platform IBD Internal Block Diagram MIL Model-In-the-Loop ACT Activity Diagram SIL Software-In-the-Loop STM State Machine Diagram HIL Hardware-In-the-Loop SD Sequence Diagram OEM ECU E/E Original Equipment Manufacturer Electronic Control Unit Electrical/Electronic UC REQ SHS Use Case Dragram Requirement Diagram System Hierarchical Diagram Page 8 of 8