MODEL BASED DEVELOPMENT FOR ADVANCED DRIVER ASSISTANCE SYSTEM - Part 2

This is the second part of a two-part blog on ADAS-MBD Part 1, you can find the first part of the blog.

This discusses the different stages of Model-based design analysis. 

 

REQUIREMENT ANALYSIS

When there is a problem in engineering, the first step to arrive at a solution is understanding the problem. The process of seeing a real-world problem, understanding it, and trying to replicate it into a MATLAB model in order to solve it, is what requirement analysis is all about. This finds a concise method to capture the functional requirements that can be used to evaluate the interaction and compatibility of requirements from different sources. From this understanding, a software model can be built.

For example, consider the problem of a Switch Control Logic. A customer can have a requirement which can be a simple task like the addition of blocks, and multiplication, a data type conversion, or switch control logic where it only takes one input out of two. Usually, the requirements come in the form of diagrams, word, or excel documents. After you have developed your model in line with the specified requirement, the next thing to do is requirement tagging and traceability. 

 

Requirement Tagging and Traceability

To tag a requirement into a subsystem;

1. Load the requirement document into a Simulink Model

2. Select the text from the requirement document

3. Keep the requirement document open to select the corresponding function to the corresponding system.

This will help you as a developer to check if all requirements were duly considered. No requirement should be missed.

 

 

MODEL-BASED DESIGN CONFIGURATION SETTING

The main objective is to convert the model into a piece of code. Once we understand the requirement, it can be converted as a code following some steps in the MATLAB environment.

In MATLAB, locate and open the configuration parameter window. Find this by clicking on Model Configuration Parameters under Simulation.

The Configuration Parameters controls a number of actions like; solver information, data validity, connectivity, and simulation target. It is used to control configuration settings.

 

MODEL DATA DICTIONARY

Just like how we define variables in C +, we can also do the same in MATLAB. However, when doing this in the model level there are hundreds of variables available, each of the different data types and dimensions. Manually defining variables in MATLAB is very tedious, so a data dictionary is used. A model-data dictionary is a composition of relevant data in our model.  The dictionary stores data that defines parameters and signals.  In a Simulink data dictionary, there are four different sections, each having variables, signals, or calibration data that are in use loaded into them and archived to avoid making further changes or definitions when carrying out further tests at the workspace level or at the script level.

 

Benefits of Simulink Data Dictionary

• Our configuration parameters can be stored.

• It allows traceability from data object to Simulink selection

• Once created, data is persistent.

 

Limitations of Simulink Data Dictionary

• Models from workspace blocks are not supported

• Signal resolution setting must be set to explicit only.

Note that making changes of signals and parameters in the Simulink Data Dictionary (SLDD) should be done directly at the SLDD level and not in the exported m-file.

 

PORT PROPERTIES CHECK

Ports are like doors in a building. The port is the point of entry; in-port is the entry port and outport is the exit point for our model. The properties of the ports should be properly defined to enable easy movement of the signal. The in-port should be placed at the LHS while the outport is placed at the RHS to ensure the flow of signal from left to right, which is the proper direction. There are a number of instructions to be followed when defining in-ports and outports, all instructions have been explained in detail in our  electric vehicle design and analysis course

 

Displaying Signal Names

A signal is a line connecting a port and a port, a block and a block, or a port and a block. A logical name must be assigned to the signal (Label). Some blocks like From Block, In-port, State-chart block, and Subsystem block must have labels attached to them.

Other factors like; Signal Properties, Signal Resolving, and Propagated Signals should also be handled. When this is done, you should have a high certainty level about the workability of the model.

 

Model Advisor

This is a tool that automatically checks the models for errors using some pre-set checks. There are certain ISO 26262 guidelines attached to each embedded software. The model advisor can be set to analyze the model either as a sub-set or entirely. Whichever method is preferred to simulate the model, open the model advisor, check and run it. The results will show us if everything was done according to the set standards or if there are errors we should correct. Although the logic of our model might be correct, it still might not meet the standard according to the ISO 26262 general safety standards. This is why we must use the model advisor and make necessary changes. Once we make the changes, we can start generating the code.

 

CODE GENERATION

This is an automated process. Once we have completed the previous stages, simply click on the BUILD icon from the Simulink icons tray, and the code is generated.

 

VALIDATION AND VERIFICATION 

Validation involves evaluating a system after the development process to check that it satisfies specific requirements. Verification on the other hand involves evaluating a system to determine whether the product at the end, satisfies the conditions required at the start. MIL and SIL testing are also seen as validation and verification. First, they are verified together to check if the final product was developed with the required procedure. Next, we validate it to check whether it is in line with our customer’s specifications. 

 

Importance of Validation and Verification

• Safety: If signals are not properly sent to parts of the vehicle, it can result in loss of lives. Also, if the brakes or other parts of the vehicle are not functioning properly, it can cause damages.

• It helps us confirm that the software does not perform any unintended functions.

• It increases our confidence level in the software.

• It prevents environmental damages and economic losses.

 

Stages of Verification and Validation

1. Functional Validation; It shows whether a logic is functional.

2. Structural Validation

TYPES OF TESTS

Unit testing: This is performed on a single component of a system.

Integration testing: All units involved in the interaction are integrated and tested.

System testing: This involves functional (The whole system is testing against specifications, and then evaluated) and non-functional (properties such as performance and flexibility are tested) testing.

Acceptance testing: This is done in a realistic environment by or with the customer. The focus is no longer to find defects, but to see the system functions.

 

Types of coverage Metrics

Coverage metrics measure model and code coverage for a variety of metrics in the testing level like;

Decision coverage: This analyzes elements that represent decision points in a model. 

Condition coverage: This analyzes blocks that output the logical combination of their inputs.

Modified Condition/Decision Coverage: This analysis by the Simulink extends both decision and condition coverage abilities. 

 

Test Report Analysis

After the metrics analysis, we get a test report. This has the basic information about the test like details, testing summary, and model information. Whatever condition is highlighted in red means the particular condition has not been tested, and needs to be tested. 

 

ADVANCED DRIVER ASSISTANCE SYSTEM (ADAS)

These are designed to increase the safety of cars and driving system. Old vehicle models required a lot of hard work, but today, with the inclusion of these features, driving is becoming less stressful. ADAS features are being embedded in vehicles all over the world today. For instance, Hyundai Creta has some ADAS features, and is being sold in large numbers in India today. 

Some ADAS features include; Adaptive Cruise Control, Autonomous Emergency Braking, Blind spot detection, Intelligent parking assistance, and cross-traffic alert.

 

Levels of Autonomous driving

Level 0 – Has no active assistance system; the driver does all the work himself.

Level 1 – Longitudinal or transverse guide.

Level 2 – Traffic control; the software algorithm ensures that as you drive, the rules are obeyed. Cameras are placed in front of the vehicle windshield, capturing traffic signals, and sending the signals to the sensors in the car.

Level 3 – Awareness for take over

Level 4 – No driver intervention

Level 5 – No driver

Levels 1 and 2 are the most common today. Level 3 is being implemented in some developed countries, while level 4 and 5 are seriously being worked on. With improved levels, comfort is improved. 

 

Major Stakeholders in Automotive

Some popular stakeholders include; Tesla, Ford, Toyota, Nissan, BMW, and others. Suppliers like Bosch and Continental are also doing great works.

 

INDUSTRY DEMANDS FOR MBD ENGINEERS

There is a high demand for qualified Model-Based Development engineers. Some of the skills possessed by a good MBD engineer include;

1. Develop your MATLAB skills to the highest level.

2. Understand requirement

3. Stick to the MBD standards.

4. Good knowledge about MIL

5. Good knowledge about embedded coder/AutoSAR

An MBD engineer can work on various parts like; Power-train control, body management, and ADAS features, depending on your interests.

CONCLUSION

In conclusion, the ADAS feature is a key feature in today’s automotive market. Model-Based Development is a very lucrative sector in the automotive world. If you need detailed information on all these, you can take our well-structured detailed course program today.

 

Check out the List of Job opportunities for your Engineering domain