■ Competitiveness is not speed, but verifiable evidence.

The advancement of generative AI is rapidly transforming software development methods. Developers can now utilize AI coding assistants to complete coding tasks that used to take hours in just tens of seconds. With AI supporting everything from function implementation and algorithm writing to test code generation, the productivity of individual developers is improving to an unprecedented level compared to the past.

However, in embedded software development where functional safety is required, such as in automobiles, medical devices, and industrial automation, the story is a bit different.

In projects that must satisfy international safety standards such as ISO 26262, IEC 61508, and IEC 62304, the biggest constraint is not the speed of writing code. The real bottleneck is the process of creating 'evidence'.

The fact that the program operates normally is not enough. Objective evidence is required regarding whether the code was written in compliance with the defined development process, satisfies relevant coding rules, and ensures complete traceability from requirements to test results.

AI speeds up code writing but does not automatically generate this evidence.

■ AI generates code, but it does not generate compliance.

Recent AI coding tools demonstrate excellent performance. They provide a significant level of results, ranging from simple function implementation to algorithm suggestions, test code generation, and code refactoring. For example, if you request that an RPM calculation function be written in C, it generates syntactically correct and logically appropriate code.

However, there is a significant problem here. While AI-generated code may be functionally sound, there is no guarantee that it satisfies compliance.

A representative example is the MISRA C rule. Even code that appears to have no issues on the surface can be deemed to have violated Implicit Type Conversion under MISRA C:2012 Rule 10.3. Such issues are reported as defects during the static analysis process, and the code is recognized as verifiable code connected to requirements only after the fix is completed.

This issue is not limited to a single specific rule. In functional safety embedded development, various international standards, such as the following, are applied simultaneously.

· MISRA C / MISRA C++
It is the most widely used safety coding convention in automotive, medical, and industrial embedded systems. It minimizes the possibility of undefined behavior by limiting the scope of C/C++ language usage. Code generated by AI must also pass MISRA rules to be applied to actual projects.

· CERT C / CERT C++
It is a standard designed to prevent vulnerable coding patterns from a security perspective. While MISRA focuses on safety, CERT aims for security. Recently, with the rise of connected embedded systems, the importance of both areas is growing together.

Common Weakness Enumeration (CWE)
It is a database that systematically classifies recurring software vulnerabilities. Since AI learns vulnerable code alongside secure code during the training process, there is a possibility that it may generate known vulnerability patterns exactly as they are. CWE serves as a standard for systematically identifying such problems.

The important point is that AI models do not check these rules on their own. Ultimately, compliance with specifications is an area that developers must verify using appropriate development tools.

■ Verification Bottlenecks That Will Not Disappear Even in the AI Era

In functional safety projects, it is common for more than 40% of total research and development costs to already be spent on verification and validation. This is not due to inefficiency. It is an essential process for establishing the extensive evidence system required by safety certification bodies.

Let's assume that AI doubles or triples the speed of code writing. What would happen if the verification process remained the same? More code would be subject to review, more static analysis results would need to be checked, and more tests would have to be performed. Eventually, the bottleneck becomes even larger.

While AI has sped up the early part of the development process (Code Authoring), the actual bottleneck exists in the later stages of development.

in other words,
· Static Analysis
· Dynamic Analysis
· Code Coverage Measurement
· Ensuring requirements traceability
· Functional Safety Approval (Sign-off)

This process determines the overall project schedule.

Therefore, increasing only the code generation speed is different from increasing the overall productivity of a functional safety project.

■ Quality is created during the development process, not at the end.

To address these issues, static analysis, dynamic analysis, and code coverage must be continuously incorporated into the development process rather than being performed at the final stage of the project. In other words, AI code generation and quality verification must take place within a single development loop.

■ Integrating Static Analysis into the Development Process

IAR’s C-STAT checks MISRA C, MISRA C++, CERT C, and CWE rules as soon as code is written. When a developer adds AI-generated code to a project, it can automatically check for rule violations prior to the review stage. The structure involves AI proposing code, developers reviewing it, and C-STAT verifying compliance with specifications. This approach significantly reduces the problems found during the code review phase.


■ Dynamic analysis performed during the debugging process

Static analysis alone cannot identify all problems. Errors that occur only during execution, such as memory errors, array out-of-bounds, integer overflows, and switch statement processing errors, must be verified in the actual execution environment.

IAR's C-RUN detects these runtime errors in real time during the debugging process. Runtime verification is becoming increasingly important in the AI era because unexpected problems can occur during actual operation, even if AI-generated code is structurally correct.


■ In the AI era, the role of developers becomes even more important

The advancement of AI is not replacing developers. Rather, it is changing the role of developers.

While the key in the past was writing all the code manually, the role of determining whether the code proposed by AI is safe, aligns with the system architecture, and meets requirements has now become more important. In other words, the role of developers is expanding from code authors to quality curators.

While AI can suggest code, the developer still needs to judge whether it satisfies safety objectives, is sufficiently tested, and aligns with the overall system design. Only with such judgment can the generated code be recognized as attested code.

■ CI/CD automatically accumulates evidence

Quality checks performed on a developer's PC are just the beginning. In team-based development, every commit must be automatically verified to meet the same quality standards. In an era like today, where AI generates code in a single day that used to take a week, relying on humans to perform quality checks for every task is insufficient. Verification must be performed automatically within the CI/CD pipeline.

IAR Build Tools enables the use of the same compiler and linker as IAR Embedded Workbench in CI environments such as Jenkins, GitHub Actions, and Azure DevOps. This ensures that the development environment and the CI environment produce completely identical build results, thereby securing a reproducible build environment required by ISO 26262 and IEC 62304.

In addition, C-STAT also runs automatically in the CI environment and continuously checks MISRA, CERT, and CWE rules for every commit. Quality evidence is not prepared all at once at the end of the project, but is naturally accumulated throughout the entire development process.

■ Competitiveness in the AI Era Is Determined by Platforms

While static analysis, dynamic analysis, code coverage, and CI/CD automation are important individually, they provide the greatest value when integrated within a single platform. The IAR platform integrates these capabilities into a single development environment.

It supports Tool Qualification for major functional safety standards such as ISO 26262 (TÜV SÜD certified), IEC 61508, and IEC 62304, and C-STAT and C-RUN also operate within the same development environment. In other words, a single, consistent Evidence Chain can be established from build to analysis, verification, and certification. This is the key factor that makes the difference between simple AI productivity enhancement and functional safety compliance.

■ Conclusion

AI will continue to generate even better code in the future. However, in embedded systems requiring functional safety, objective evidence to prove quality is far more important than the code generation itself. AI writes the code, but obtaining certification is the development process and the verification tools that support it.

Competitiveness in the AI era depends not on how quickly code is generated, but on the ability to consistently produce reliable evidence of quality. At the heart of this lie development platforms and verification tool systems that support safety certification, and to simultaneously satisfy AI and functional safety, an integrated development environment capable of securing both productivity and quality is becoming more important than ever.

※ [Reference] Code Quality and Compliance - Building Stronger Code with IAR
https://www.iar.com/ko/embedded-development-tools/code-quality-and-compliance