Model-Based Development Summary

Model-Based Development Summary

Object:
Automotive Electronics Embedded Application Layer Development
Environment
: Simulink
Advantages:
1. Good at dealing with complex timing, logic, and operations (fixed-point mathematical operations)
2. Functional verification tests can be completed based on PC
3. There is no basic Syntax problem
Process
: 1. Requirement analysis
2. Framework design
3. Modeling
4. Unit testing
5. Integration testing
6. System testing The points to be noted in the
above 6 steps are as follows:

1. Requirement analysis
   Pay attention to the following points:
   a) Requirement capture is listed one by one by function. Break the
   whole into zeros , and confirm one by one so as not to miss out as much as possible. At the same time, it can ensure the traceability of upward SOR and downward model design and testing.
   b) Requirement is divided into former Set conditions, execute actions, and output results
   . Doing above distinctions is convenient for later modeling to clarify data flow and testing.
   c) Document
   traceability Only traceable documents, models, codes, and tests can be logically persuasive
   . Output: requirements analysis document

2. Framework design
   Framework design is the most test of skills. A good architecture not only needs to know the functions well, but also needs basic modeling literacy.
   A good architecture needs to meet the following conditions:
    Good readability (at a glance, the functional intention can be clearly understood through the architecture)
    Good maintainability (generally speaking, it is easy to reduce functions and increase functions difficult, reserve interfaces or reserve parallel input Condition)
   Output: data flow (architecture design document I feel that data flow is enough)

3. Modeling
   After the requirement analysis and architecture design are completed, the model building is a matter of course. Modeling details need to be accumulated.
4. Unit testing
   Unit functional testing, does not involve functional conflict testing. Generally, only MIL (model in the loop) test is performed, and the requirements analysis document can be improved synchronously and retrospectively. In view of the fact that the MIL test has been completed, the SIL (software in the loop) test can be done by using its test conditions. To explain, SIL is only to ensure the consistency of model behavior and C code behavior, even in a very mature Simulink platform, it does not rule out a small probability of errors (although I have never encountered it, but because of the small workload, it is still It is recommended to do it)
5. Integration test The
   integration test is mainly an interface test, which can be synchronized and traced to improve the data flow document
6. System testing The last thing to pay attention to in
   model development is system testing. System testing is very important. It directly reflects the functional realization of each functional module of the entire model and each other. Usually HIL (hardware in the loop) test or bench test. The PIL (processor in the loop) test is omitted here. The behavior of some processors may be different from the behavior of the C code. If it is not a particularly unpopular processor, and if there is no subsequent bench verification, you can consider the cost and effort of the call Go to PIL. After the HIL test is completed, basically all bugs can be solved. As for the follow-up labcar and real vehicle tests, most of the problems are related to other on-board modules, electrical appliances, wiring harnesses, and mechanical structures. There are almost no problems with the model itself. Generally, it needs to be calibrated. If this cannot be solved, then the problem of the requirements itself must be considered.
   note: Regarding the modeling specification, use the MAAB test. After passing, I believe that the readability and reliability of the model will be greatly improved.