Search Results

Many automotive ECU system issues do not manifest themselves until later in the vehicle product development cycle, despite the extensive testing and stringent validations that the ECU may have gone through. When such a system-level issue is identified, engineers will traditionally rely on the available information collected from logged DTCs and memory dumps to root-cause the issue. They will then develop a solution that will either eliminate the defects in ECU or develop a robust design to mitigate the impact. However, engineers are faced with technical difficulties which include: (a) physical addresses for many RAM variables critical to find the root-cause are subject to change with various releases of software, (b) some variables “come and go” so it is challenging to find out how and when the undesired events happen, and (c) many variables that are needed to identify the root-cause are missing.

An effective methodology for design verification and product validation is always a key to high quality products. As many body control applications are currently implemented across multiple ECUs distributed on one or more vehicle networks, verification and validation of vehicle-level user functions will require availability of both the vehicle networks and multiple ECUs involved in the implementation of the user functions. While the ECUs are usually developed by different suppliers and vehicle networks' infrastructure and communication protocols are normally maintained and developed by the OEM, each supplier will be faced with a similar challenge - the ECU being developed cannot be fully verified and tested until all other ECUs and their communication networks are available in the final development stage.

The application of Model-Based Design (MBD) methodology to software development for automotive Electronics Control Units (ECUs) cannot be fully realized without auto-code generation. Auto-code generation does not lend itself directly to projects where carry-over designs and legacy code have to be utilized due to either budgetary limitations or customer requirements. In fact, the majority of existing ECUs still contain only manually-written embedded software and many projects only involve requirement changes and/or added functions. In this case, it is not practical to discontinue the usage of legacy code and create a full model for the purpose of auto-code generation. In this paper, we describe a methodology in which auto-code generation approach is leveraged by creating MATLAB® models just for new features and/or change requests.