Write at the beginning
First of all, I have to admit that this article should be of general attention to all automotive electronics development, especially software developers.
Secondly, I have to admit that the statistics of this article are still very difficult, because it is difficult to guarantee that there will be no missing content.
Finally, if you have passed the qualification certification but did not reflect it, and would like to be included in our statistics, please feel free to contact us.
Why use software tools?
First of all, I must declare that I am a layman for software tools.
Secondly, in the ISO 26262 projects that we have completed the certification in the early stage, such as Changan New Energy, we will not force the other party to use a specific tool in the development.
Again, the purpose of writing this article is for your convenience, because we often need to answer the same questions repeatedly. [If you need related software, you can also contact me 18601196114]
Finally, there seems to be no one but us who can calculate the corresponding data relatively completely, because the internal database with relatively comprehensive information is only open to internal personnel.
The reason is that
First of all, the greatest significance of software tools is to improve work efficiency and reduce ManPower costs. I have no channels to make specific statistics, so I can only quote some data (thanks to SafetyOffice for the kind support)
Second, in fact, in many cases, using software tools with specific functions is a helpless choice, for example:
Concept phase
--We have to have Safety Goal and FSR, we need to assign a unique ID number;
System phase
--The ID number is required after the TSR is refined;
--On the left half of the V process, an ID number is required after the security mechanism is initially defined. The key is that you need to match the security mechanism with the security requirements. The lack of an ID number can kill you.
Then decompose the security requirements into each functional sub-module, otherwise the design cannot be done, each module needs an ID, each sub-module also needs an ID, and each sub-sub-module also needs it;
--On the right half of the V process, many testing and verification requirements must also have ID numbers, and they must also correspond to safety requirements. Otherwise, if you encounter a bad-tempered OEM, you will definitely be criticized....
At the hardware and software stage, if you do the development yourself, we won’t go into details. Anyone who has done development knows...
If you don’t do your own development, you have to assign it to Tier2. Maybe Tier2 will have to find Tier3. There is no systematic ID number system. No one can know how far it can be done after design, development, testing and verification. It only depends on the sense of responsibility and people. Tasting...
in other words
Without software tools to help you manage it, ID numbers are already terrifying. The key is that you have to connect the whole chain from requirements→design→test verification, and then complete two-way traceability.
And in the future, you need to know clearly, based on a specific requirement change, the affected design test verification will include which ID number corresponds to the work. It is too difficult without tools to help.
Third, sometimes OEMs will ask you to use a certain software tool, no matter how bad you think that tool is;
Finally, software tools are also regarded as fixed assets after all. In this era when currency is over-issued and M2 continues to expand, the money in one's hands has to be invested in order to be harvested.
Rough classification of software tools
Here is just an example, not fully expanded
After I buy the software tools , how can I use them to comply with ISO 26262?
First, people make mistakes, and software tools can make mistakes. It is absolutely undesirable not to do comparative verification, and to believe 100% of the results generated by software tools.
Secondly, in the process of using software tools, we need to verify the impact of software tools on safety functions (TI), and at the same time evaluate the software tools, in view of their possible internal error diagnostic capabilities (TD), and finally generate the software The confidence level (TCL) of the tool.
Third, we need to evaluate the tool, which should include the type of tool, which specific development stage it is used in, the configuration method, the development method, the application environment and the specific purpose, and finally the TCL confidence level of the tool. And in principle, the verification of software tools needs to be continuously maintained during use. If anyone unconditionally believes in any results output by the software tools, then congratulations, and bless you at the same time!
Is it necessary to purchase software tools that have passed ISO26262 ?
The ISO 26262 standard does not clearly state that you must buy certified software tools. We often see simple and easy-to-use small non-commercial software tools developed by customers themselves, and their functions are also very powerful.
In actual projects, outsourcing high-quality software tools will definitely improve work efficiency. Moreover, the application of compliant software tools is also a bonus item on the OEM client. If people value this item, you can’t use it.
In business, if you develop ECU, ISO 26262 compliance may not be important, whether or not software tools are used may not be important, but whether the product can be sold or not, whether the OEM can buy your account is really important. If the OEM asks every day how you are doing in the functional safety development based on ISO 26262, and asks you every day if you have a certain software, can you not use it?
Which software tools have obtained the official ISO 26262 certification?
The following list is taken from the system and is for reference only.
Remarks:
-
All the software tools in the above table have completed the ISO26262 software tool qualification certification.
-
The above statistical rankings are in no particular order, and are automatically sorted based on the end time of the certification. In addition, some ongoing software tool certification projects are not within the scope of statistics.
-
The above statistics are incomplete statistics. Due to the frequent changes of software versions, some tools may not be included in the statistics.
-
The parts marked in yellow and highlighted above are safety OS-related items.
-
How to interpret the certificate number, such as Z10.16.07.96476.001 , where Z10 is the type of certificate that does not need to be too tangled, 16.07 is the certificate issued in July 2016, 96476 is the company code, and 001 is the serial number of the certificate issued by the company. That Z10.15.11.67052.021 specific meaning is this: in November 2015, MathWorks won its first 21 certificates in the field of ISO26262, ISO26262 Americans seems really very seriously, admire!
-
Even if some software tools have not been certified for the time being, it does not mean that their compliance is poor. Maybe someone is doing certification, but we don't know it.
Has any domestic software tool obtained ISO26262 certification?
This should not be there, but Japan and South Korea do. The first software verification tool supplier in Asia to pass ISO26262 certification should be GAIO.
Are there any software tools that have passed ISO 26262 certification in China?
Seems not! But just around the corner!
Is there a safe OS that has passed ISO 26262 certification in China?
There must be! More than one!
**My mobile phone number has call attributes and WeChat add friends attributes.
I look forward to communicating with you
I’m Mave Diao,
there is only one China Unicom between us
186-0161-9614**