Toyota Motor Corporation

– Please tell us about the automotive system domains you are responsible for developing and your responsibilities.

Mr. Baba :

In our department (Powertrain Electronic System Development Dept.), we are responsible for electrical and electronic components that control the automotive powertrain.
Our department is in charge of developing overall electronic components, including ECUs that operate engines and transmissions, their control software, and sensors.
Among these, our group specifically handles communication and functional safety design.

Mr. Yajima :

I am responsible for designing the computers that control powertrain components, such as automotive engines and transmissions.
We cover a broad range of vehicle models, targeting computers installed in the powertrains of all conventional (non-hybrid gasoline and diesel engine) vehicles.
In terms of the development process, control engineers are separate; my role involves driving various control developments from a functional safety perspective, as well as promoting functional safety in the hardware aspect as components.

When I first joined the company, I was in charge of middleware in control computers, and later served as a system engineer for control computers. As the number of components subject to functional safety increased, a team-based organization was established to address functional safety, and I became a member of that team, which brings me to where I am today.

Regarding our scope of work in functional safety, the main responsibility is receiving the TSC (Technical Safety Concept) and TSR (Technical Safety Requirement) and decomposing them into SSR (Software Safety Requirement) and HSR (Hardware Safety Requirement).

Mr. Yajima :

In terms of the V-model development process, our department has historically been mainly responsible for HSR. In addition to our conventional primary function design, we came to cover functional safety as well.

Mr. Baba :

Efforts to comply with ISO 26262, the standard for functional safety in the automotive domain, began around 2011. Going back even further, when electronic throttle control spread in the 1990s, automotive industry associations led an initiative to establish principles for safety design.
At that time, safety design involved acquiring accelerator pedal signals through multiple channels and using mutual microcontroller monitoring so that, even if a failure occurred, electronic throttle output would be limited across multiple channels to fail safe.

Onishi :

In terms of electronic control, that means you have been dealing with this since the days of 8-bit and 16-bit microcontrollers.

Mr. Baba :

Yes. Of course, we were implementing safety design even before the ISO 26262 functional safety standard was established. You could say we built upon a history of accumulated safety design practices to address functional safety. In preparation for the publication of ISO 26262, we deepened our understanding by reading the original text, and we also learned extensively from European safety design based on EGAS (a European initiative similar to functional safety).

Onishi :

You mentioned addressing functional safety even before ISO 26262 was issued. Were there specific items that had to be considered precisely because of ISO 26262?

Mr. Baba :

To comply with functional safety, ensuring document traceability is required right from the upstream stages of the development process. Although the core development activities themselves did not change drastically for functional safety, it was challenging at the time to thoroughly analyze documents from the upstream phase and link them to detailed designs and analysis results while ensuring traceability.

Onishi :

I believe that traceability between deliverables is typically ensured by assigning IDs and clarifying the connections between documents. On the other hand, Safilia—which you are currently using—serves as a tool to ensure safety mechanisms (SM) at the system level and link them to actual implementation. Could you tell us what initially sparked your interest in Safilia?

Mr. Yajima :

Previously, we managed traceability manually by linking documents using IDs. To picture it, traceability was ensured simply by writing the same ID in both Document A and Document B. However, as systems became more complex and the number of target products grew, we felt we were reaching the limits of doing this manually. Furthermore, we had a growing desire to focus on our core responsibility—designing safety mechanisms to guarantee safety. This inspired us to reduce human effort in managing traceability itself by adopting a tool.

Onishi :

Safilia's description model is based on SCDL, but what methods did you previously use to express safety concepts at your company?

Mr. Yajima :

We were not using modeling languages like SysML for safety concepts; instead, we relied on our own proprietary block diagrams. That was actually another reason we chose Safilia. Safilia uses SCDL (Safety Concept Description Language), and when we tried applying our existing block diagrams to it, SCDL proved easier to understand (compared to SysML). In short, the strong alignment between SCDL and our internal standards was a major factor in adopting Safilia.

Onishi :

In which areas of development are you utilizing Safilia?

Mr. Yajima :

In terms of the processes handled by our department, it covers a relatively narrow scope, but we use it specifically for almost automatically establishing traceability between diagrams and requirements.

Onishi :

Regardless of which tool is used, customers often remark that establishing traceability is quite burdensome because they still have to manually create links, or that it is difficult to maintain. How do you feel about that aspect?

Mr. Yajima :

From a traceability standpoint, having features where added requirements are reflected simultaneously across various views and automatically updated bidirectionally is extremely beneficial.
From that perspective, GAIO implemented views based on our requests that feature highlighting capability.
Previously, we inspected the connections between requirements manually. By implementing highlighting features that show hierarchical relationships between requirements, allow filtering by requirement groups, and display relationships between requirement groups themselves, the manual effort required to verify safety concept design results has been significantly reduced, which is a major benefit for us. 

Onishi :

Could you share how you foresee utilizing Safilia going forward, as well as the potential for this tool to expand within your company?

Mr. Yajima :

To maximize benefits across the entire development process, I believe it is effective to involve both preceding and succeeding processes at each stage.
However, when it comes to spreading tool adoption, there are certainly challenging aspects.

Mr. Baba :

If not only our department but also upstream and downstream departments that exchange documents start utilizing it, end-to-end traceability can be established. Moreover, when requirement connections change, all downstream processes can capture those changes. However, regarding whether other departments will introduce the tool, there is a mindset that when existing assets already exist, slightly modifying those assets feels easier. It would be great if there were an opportunity to start something from scratch, but since work spans multiple departments, changing everything is quite difficult in reality.
Given this situation, we believe that if we use it first and demonstrate its benefits, we can gradually bring others on board.

Mr. Yajima :

The largest part of the process we handle is decomposing TSR into HSR and SSR. However, since software internals are finely divided across multiple departments in our company, we create an overall document for functional safety software and request related departments to detail the SSR. When creating these documents, we want to save labor by utilizing Safilia's XML data, thereby gaining even greater benefits across processes.

As for what we desire from the tool, we currently plan to leverage the XML export function in various ways, but having something like an API would allow for even more versatile use cases.
There are tools in the market that cover the entire functional safety process and handle traceability in a single package, but we feel it is difficult for a company with an established development process to adopt such tools as-is.

Mr. Baba :

Recently, with the increase in remote work, we can no longer print documents on paper and check them with highlighters side-by-side during reviews like we used to. On the reviewing side, documents under review are suddenly popped up on screen to start explanations, which can be tough when dealing with complex content. Our expectations for Safilia include features that make it easy for screen reviewers to identify differences or changes at a glance, or easily spot accidental regressions or unintended modifications.

Onishi, Fujibayashi :

Some of these capabilities are already present in Safilia, while others have yet to be fully implemented. We will continue to support your company so that you can utilize Safilia even further, and we will offer usage proposals to enhance the benefits of Safilia during reviews.

Mr. Baba :

In our department, we want to further promote digitalization. The volume of information is immense, and relying on manual labor and visual inspection has its limits. We want to actively leverage tools like this to transform the way we work through digitalization.

In this interview, Toyota Motor Corporation's Powertrain Electronic System Development Division shared how they utilize Safilia for safety concept design required by ISO 26262 and for reviewing deliverables. In light of our customers' digital transformation (DX), GAIO TECHNOLOGY will continue to provide comprehensive support and proposal activities to ensure the traceability of functional safety deliverables and drive effective tool utilization.

From left: Mr. Yajima and Mr. Baba, Electronics Development Dept. No. 21, Powertrain Electronic System Development Div., Toyota Motor Corporation