Implementation of ISO Check For Early Failure Detection in Vehicle Design Using FPGA

To be more concerned with the fatal cause during the real time experiences in automotive industry in the ECU failures, it shall be a preventive measure to detect the failure of the ECU’s at the probation period of modelling it. MATLAB, the tool used for designing the ECU’s would be useful also to check this with the help of its inbuilt tool called MODEL ADVISOR. With the m-script, we can use to customize the rules for which there might be the reason for failure. Some of the model level failures are detected using this model checker tool. Before we dump the code into FPGA or an ECU, the code level failures can be detected via polyspace, which is also a tool by MATLAB. With this earlier detection of failures before dumping the code into ECU, this saves the lives of many people during the emergency situation when there is a possibility of failure of ECU. Also production loss of the component can be reduced along with this the standardized product can be released, so that it would be the safe for use.


Introduction
Whenever we go for the creation of new component for a vehicle, we go in for the specific design which would be user friendly, to have an overview about the description of the actual component we require. As per the confidentiality for the specific component designed by a product designer, it is required to encrypt the design. The conversion of a Simulink model to s-function suits good in this case.
Conversion of a MATLAB Simulink model to FPGA (Field Programmable Gate Array), and doing a test validation helps in the final sanity check before we program the code into the specific ECU. Also to be confident for the fatal cause of the component design, we have to ensure for the ISO compliance check, which can be done via the Model advisor which is present in MATLAB. The specific customized rules can also be integrated to make a compliance check.
This precautionary way helps the Component designer or the product based company to provide a standardized component\product, So that it would be better accreditation in terms of seller perspective. When it comes to the Consumer perspective, this brings in a satisfied feel of buying it with safety as the main concern. The deployment of the code into the ECU without testing, and getting into the stage of production and later on during the real time experiences, this model gets failed, the production and recycling it would be time consuming as well as the man effort loss along with the wastage of materials used for ECU.

Literature review
Saiful A. Zulkifli  Bassoli [3] have proposed, Automotive instrument cluster screen content validation [3],describes a novel solution to provide this kind of screenshots to the car manufacturers, called Image Grabber application, using a DSLR digital camera, a CAN case and a C# tool. The proposed solution has no original equipment manufacturer limitations, as it can be used on all types of clusters and provides an implementation cost decrease of up to 10 times, when compared with a similar hardware grabber system. Cheng et al [4] have proposed Design guideline of the EMB controller based on ISO26262 to analyse the failure modes which are required in ISO26262 Part 5, 6. And we propose design guidelines to meet safety requirements. In addition, the EMB system was implemented based on the proposed hardware and software guidelines [1]. The implemented EMB system meets Part5, 6 of ISO26262. Therefore, the proposed guidelines are made good use for product development to meet Part 5, 6 of ISO26262. In this paper, we have studied fault diagnosis function, and fail safe function should be needed to study.
Alfredo Imparato, Raffaele Rodolfo Maietta have proposed, A Comparative Study of Static Analysis Tools for AUTOSAR Automotive Software Components Development [5], following automotive safety standard ISO26262 to reduce software runtime errors. A comparative study of top performance tools is provided by analysing production code of AUTOSAR application software components for an Instrument Panel Cluster. A quantitative analysis based on an alert classification model and performance metrics has been carried out [6]. The goal of this paper is to identify the best combination of commercial static analysis tools to minimize defects of AUTOSAR software components in a context of automatic code generation. Finally, the results analysis has suggested some improvements of static analysis tools.

Imparato et al have proposed Formal Verification of Automotive Design in Compliance With ISO 26262 Design
Verification Guidelines [7], to compare industrial design verification steps of WatchDog Manager in an effort to be ASIL B-compliant with a proposed no disruptive methodology to semi formally verify WatchDog Manager UML design via an automated formal framework backbone [9]. This semiformal verification framework will allow automotive software to comply with ASILs C and D formal and semiformal unit design and implementation verification recommended guidelines in ISO 26262. Semiformal UML finite-state machines are automatically compiled into formal notations based on the Symbolic Analysis Laboratory formal notation Zulkifi et al [19] have proposed the Functional safety methodologies for automotive applications, introduces some basic concepts of functional safety analysis and optimization and shows the bridge with the tradition design flow. Considerations are presented on how design methodologies are capturing and addressing the new safety metrics.

Proposed work flow
To model for the particular component to be designed using Simulink -MATLAB. Converting the model (.slx) to the code VHDL and then to check for FPGA outputs. There are 3 possible cases: ASIC design, FPGA simulation output and Hardware design output. We go for the FPGA, to make sure for the compliance check.
The proposed work flow is show in the Figure.1. There are group of development persons involved with more skills and with modeling practice. In this challenging development environment, implementing modeling guidelines to ensure modeling consistency is vital. Modeling guidelines establish a homogenous approach within the design team, making it easier to reuse the models for new projects. Guidelines also help new members of the team become familiar with your development process.
For some projects, it is a best practice to use the modeling guidelines into the model. Software systems deployed in high-integrity applications in aerospace and other industries must satisfy rigorous development and verification standards. Industry standards such as ISO 26262, EN 50128, IEC 61508, and DO-178C make modeling guidelines a prerequisite.

ISO Rules
The approach recommended will enable to efficiently apply the standard within the modeling team and ease the qualification of your modeling guidelines. The violations are been reported when the certain ISO rule in not followed. Also the AUTOFIX option shall be introduced if there is any possibility of fixing the model is possible. The ISO rules are shown in the • Signal names shall be defined for signal lines that output from important blocks. The signal name shall be provided once, at the origin of the signal line.
• A label shall be used to display defined signal names.

Rationale:
• Defining the signal name and displaying the label for the output of meaningful results from important blocks improves the readability of the model.

Description:
• When defining the signal name for a signal that extends across a hierarchy, signal property Show propagated signals shall be selected so that propagated signal names are displayed.
• In a subsystem with a library • In subsystems where reusable functions are set • A signal name is not set at the out port signal of the Bus Creator block

Rationale:
• Prevents signal line connection mistakes.
• Prevents signal line name mistakes.

DB0097 :position of labels for signals and buses:
Description: • Signal line labels and bus labels shall not overlap other labels, signal lines, or blocks • Signal line labels and bus labels shall be positioned at the origin of the connection.

Rationale:
• Adherence to this rule prevents confusion with corresponding names, signal lines, and buses, which improves readability of the model.
• Consistent label position prevents confusion with corresponding labels, signal lines, and buses, which improves the readability of the model.

NA0008: position of labels for signals and buses:
Description: • A label shall be displayed on the signal line originating from these blocks: • Inport From (see exception).
• Subsystem or Stateflow Chart (Stateflow) (see exception) • Bus Selector (the tool forces this to happen) • Demux, Selector, Data Store Read (see exception),Constant (see exception)

Exception
• When the signal label is visible in the originating block icon display, the signal does not need not to have the label displayed unless the signal label is needed elsewhere due to a destination-based rule.
• Code generation may not be possible.

NA009: Entry versus propagation of signal labels
Description: • When a label is displayed for a signal, the following rules define whether that label is created there (entered directly on the signal) or propagated from its true source (inherited from elsewhere in the model by using the < character).
• Signal labels shall be entered for signals that originate from: • The Inport block at the root (top) level of a model • Basic blocks that perform a transformative operation (For the purpose of interpreting this rule only, the Bus Creator, Mux, and Selector blocks also perform transformative operations.) • Signal labels shall be propagated for signals that originate from: • Inport block in a nested subsystem • Basic blocks that perform a non-transformative operation • Subsystem block or Stateflow Chart (Stateflow) block.

Exceptions:
• When the nested subsystem is a library subsystem, a label can be entered on the signal coming from the Inport block to accommodate reuse of the library block.
• When the connection originates from the output of a library subsystem block, a new label can be entered on the signal to accommodate readability.

Rationale:
• The result of executing a MATLAB command is reflected in the code, which makes consistency between the model and code difficult to maintain.

JC201:Usable characters for subsystem names
Description: • Only these character types shall be used in structural subsystem names: • Single-byte alphanumeric characters (a-z, A-Z, 0-9) • Single-byte underscore (_) • Line breaks, single-byte spaces, double-byte characters, and control characters shall not be used.

Rationale:
• Cannot generate code using the configured structural subsystem name.
• May not be able to generate code using the configured structural subsystem name.

jc_0231: Usable characters for block names
Description: • Only these character types shall be used for basic block names:

Research Article
Vol. 12 No.6 (2021), 1792-1802 • Single-byte alphanumeric characters (a-z, A-Z, 0-9) • Single-byte underscore (_) • Line breaks and single-byte spaces shall not be permitted when adding a new block name. However, they shall be permitted when used initially as a block name that is saved in the Simulink library.
• Double-byte characters and control characters shall not be used.

Rationale:
• Deviation from the rule can make it difficult to maintain the integrity of the model and code.

jc_0211: usable characters for in-port blocks and outport blocks
Description: • Only these character types shall be used in Inport and Outport block names: • Single-byte alphanumeric characters (a-z, A-Z, 0-9) • Single-byte underscore (_) • Line breaks, single-byte spaces, double-byte characters, and control characters shall not be used.

Rationale:
• Deviation from the rule can make it difficult to maintain the integrity of the model and code.

JC0243: length restriction for subsystem names
Description: • Structural subsystem name length shall be a maximum of 63 characters.

Rationale:
• Code generation may not be possible.

JC0008: definition of signal names
Description: • Signal names shall be defined for signal lines that output from important blocks. The signal name shall be provided once, at the origin of the signal line.
• A label shall be used to display defined signal names

Rationale:
• Defining the signal name and displaying the label for the output of meaningful results from important blocks improves the readability of the model.

Results and Discussion
The above listed rules are integrated in the model advisor and then it is checked for the model whether it is followed or not. When the rule is not followed, the current check for which the rule is not followed, violation will be thrown.  When model level failures are been corrected the code level failures as shown in Figure.4, in case of overflow detection, precision losses, underflow detection, can be found with the help of polyspace, the tool by MATLAB, which is the static code analyzer. When all those model level and code level failures are detected and resolved, it is more or less effective for the deployment, with the standardized product. Now the code can be deployed and the sanity check can be effectively found in FPGA as shown in Figure.6. The finalized implementation is shown in Figure.7. Figure.7 FPGA board manager wizard

Conclusion
As a result of any fatal failures, the main drawback would be from the design perspective. So when the designs are corrected in the earlier stage this would be more useful to reduce many problems. So making the ISO check into consideration, the product becomes a standardized one. Also the code generation check would be helpful to reduce the memory consumption of the ECU, in case of removal of any unreachable code. When the standardized design and code is deployed in the ECU, the component reaches the best quality level in the market and also it acquires the customer satisfaction rating to its peak.