Talk:Embedded Control Systems Design/The design process

= Model based design =

The model-based development of a modified functionality or a new functionality generally follows the same development stages. This part is specifically for automotive applications, but should be pretty much the same for all systems •	First stage: functional design The functional description of the system is translated into a model of the software functions. This model should represent the operation of the end-program with the inputs and outputs the implemented system will receive. This model used to be represented by written software specifications. This approach has as major drawback that it is not easy to couple the written specifications-model to the models available for other subsystems in cars, since these are modeled in another language. Therefore the trend is to construct the functional model in a general description language like block diagrams or finite state machines (link wikibook), by use of eg. Simulink. This enables the designer to link the software-model to models of the other sub-systems of the vehicle. These subsystem-models could be implemented in Simulink as well, or could be modeled in a specific program that provides a Simulink interface, like VirtualLab from LMS for example. Usually these vehicle models are kept as simple as possible, and only need to be valid in the target operating range of the system under design. It is obvious that the complexity of the vehicle-model will always be a function of the system under test. A model for designing an adaptive cruise-control will not require a very detailed tire-model, where a model for ESP-design will need just that. If the description is unambiguous it is also possible to use the development software to perform a simulation on this functional model. No hardware decisions are made yet in this stage.

•	Second stage: rapid prototyping During this stage the functional model of the program will be tested on an actual prototype. To be able to perform this test, the development-software has to be able to convert the model to a runnable program. The newly developed or adapted software functions are then connected to the setpoint generators, sensors and actuators in the vehicle. To enable this connection, the program should be able to run real-time. This demands considerably more computing power than standard ECU’s since the generated code will still be un-optimized. How the new program is connected to the existing systems is dependent on wether it is a modification of an existing functionality or the design of an entirely new function. If the prototype is meant to test a modification of an existing functionality, then a “bypass” connection will be used (figure bosch). In this case there should be an ECU that runs the basic program, receives all the inputs, sends all the outputs and has a bypass interface which can be connected to the experimental system. The software on the ECU should also support the possibility of sending data to the experimental system and substituting the ECU-outputs with those from the experimental systems. The software modifications required are called “bypass-hooks” (source Bosch). This method is also advisable if the ECU for the system under test has complex I/O processing, eg for an engine ECU, because it would be unwanted to program these processing protocols all over again. If the purpose of the prototype is to test an entirely new function, normally a “fullpass” system is used. In case there is no other ECU required, and the experimental system takes care of all the I/O and processing functions. This also means that the experimental system should be able to communicate with all the necessary setpoint generators, sensors and actuators.

•	Third stage: Implementation In this stage the actual hardware for the vehicle is chosen (more info on hardware? Wikibook? Here?). This determines extra constraints and requirements for the function. The program has to be implemented for this exact type of hardware to work as optimal as possible, so that the most economical hardware setup can be used. In the past this programming always had to happen by hand, which was very time-consuming and rather error-prone. Nowadays however, more and more developers are introducing development programs which are able to do an automatic optimal compilation of the program based on a given hardware configuration. This obviously saves a lot of development-time and makes iterations in or after this stage much easier and faster. This is also the stage where all the requirements have to be taken into account, going from real-time behavior, to reliability to diagnostic possibilities. (is niet echt all the requirements) Since all the electronic systems in the vehicle are being developed in parallel, it is also crucial that all the communication is well implemented in this stage. This is currently one of the most time-consuming activities, due to a lack of standardization of communication between ECU’s.

•	Fourth stage: integration and testing This is the stage where all the individual components are synchronized. The entire vehicle system is tested in a protected environment like test-benches and hardware-in-the-loop (HIL, Wikipedia). After this stage, there shouldn’t be any major bugs in the system anymore. One of the main problems during this part of the development is the choice of test cases, and what tests reveals flaws the best.

•	Fifth stage: calibration of software functions In this final stage, the final ECU-parameters are calibrated. Because not every parameter can be determined through laboratory testing, the final fine-tuning has to happen on the actual vehicle. Some calibration, like engine-calibration, can happen on test-benches as well though. This calibration can happen off-line, but this has the disadvantage that the operation of all the components has to be interrupted to update the system-parameters. The alternative is to perform an online-calibration. With online-calibration, the parameters can be adjusted while all the microcontrollers are running. This does place higher stability demands on the system.

=Motivation of changes in Cross-sectional issues=

The deleted sections: communication, quality, resources contained no information relevant to the design process. A lot of information could also be found at wikipedia. Unless you can give clear advice, i.e. do's and don't's, about them in regard to system design there shouldn't be a section of them.

In the late design commitments section the text was improved (say more/the same with fewer words).