Fuji Kiko Co., Ltd.

Domains Involved in Development and Operational Details
First, our guests introduced themselves and shared their career history and responsibilities at the company from when they joined up to the present.

– Could you please introduce yourselves and tell us what products you are currently involved in developing?

Regarding the field of electronic control, before becoming involved with electronically controlled shifters, I had only heard rumors that some other department was developing electrical components. Following various corporate movements and organizational changes, electrical and electronic components were positioned as key future products, and I was recently appointed as Manager of Design Section No. 2 in the Powertrain Design Department.

Since shifters are physically operated by human touch, mechanical elements such as responsiveness to human movement are crucial. While they naturally contain moving mechanical components, these are electronically controlled. I believe I was appointed to my current position with the purpose of integrating both mechanical and electronic disciplines.

Automotive shifting operation directly affects drivability, or what is referred to in Japanese as "sensory performance" (kannosei). In the final stages of shifter development, sensory evaluation and response evaluation involve fine-tuning and seasoning tailored to client requirements. Getting client approval on these aspects is an exceptionally challenging part of the work.

Currently, I belong to the Electronics Technology Group and design control systems. Originally, our company's products were purely mechanical, but about 10 years ago, as the wave of automotive electrification emerged, addressing this challenge led to the establishment of this department. Against that backdrop, as industry-wide adoption of automotive safety design progressed, our company was also compelled to comply with functional safety, which we have been working diligently to navigate.

Within that scope, I am responsible for system design, corresponding to Part 4 of the ISO 26262 functional safety standard. I am in charge of designing control system architectures involving both hardware and software.

– Could you tell us about the shifters you are developing?

Mr. Onishi :

A shifter refers to the shift lever mechanism of an automatic transmission in an automobile. A long time ago, everything was mechanical and connected directly to the transmission. Wires and rods were connected straight to the transmission gears, operating the transmission by pushing or pulling those gears. Therefore, the shifter was a component that could not function on its own, only operating when connected to the transmission.

For this reason, defining specifications and designing the shifter could not be done standalone; we had to establish the shifter's specifications while assuming how it would perform when connected to the transmission.

Although shifters today are completely digitized, as a vehicle interface component, the importance of operational feel and visual and tactile texture remains unchanged from the mechanical era. However, following digitization, connection is made via shift-by-wire and decoupled from the transmission mechanics. As a result, feelings such as shift feedback and operating force—which were previously achieved in combination with the transmission—must now be satisfied by the shifter alone. While the apparent specifications have not changed, the internal mechanics and implementation methods are entirely different.

– Do you use virtual environments or models when determining the control specifications for shifters?

Mr. Iida :

Shifter specifications include aspects such as the tactile feel of the knob and the stiffness or softness of the lever. However, what is crucial is that it engages in the intended position with the amount of force the driver expects when operated, and that a fast response is achieved during gear shifts. I believe these factors combine in complex ways to determine the final operational feel.

In the case of electronic control connected to the transmission via shift-by-wire, we first conduct experiments and evaluations on the shifter as a standalone unit internally. Ultimately, however, we tune the shifting operations in collaboration with the manufacturer of the connected transmission.

Before tuning the connection with the transmission, we also conduct experiments and evaluations in a virtual environment. Leveraging our accumulation of past performance data and know-how, we thoroughly perform calibration in the virtual environment to ensure it matches the physical hardware before proceeding to final tuning on the actual hardware.

– Could you tell us what initiatives you have undertaken in writing specifications for shift control?

Mr. Onishi :

Many domestic shift-by-wire products and shifters did not yet incorporate control elements, acting primarily to detect operations. However, a requirement arose asking us to handle control as well, keeping the control loop self-contained within the shifter. Therefore, we pondered how to organize shift control internally. Initially, I was working on this alone. But since I couldn't build everything myself, I needed to convey those specifications to other engineers.

When designing shift operations including control, we decided to gradually model and examine aspects like sensors and detection targets, which led us to start working with 3D models and computational models. Requirement specifications provided by automakers are often written in natural language, which cannot be directly used as control design specifications. For this reason, partly to organize and streamline things before handing off specifications to our partner companies or other departments, we started by expressing the control using block diagrams and communicating specifications that way.

It was during this process that discussions about functional safety emerged, and determining how to express functional safety design specifications became a challenge. At first, we wrote them using block diagrams through trial and error. The ISO 26262 standard was difficult for us to understand, and we struggled with it.

– We understand that system control specifications are described using "SysML." Could you tell us how this is done?

Mr. Onishi :

In control design, while we create state machine diagrams if necessary, we basically author specifications using "SysML." Back when I had no knowledge of it at all, I had only heard rumors that "something called UML exists." Looking into literature, I felt that UML was suitable for describing software behavior, but a bit off for writing specifications at the granularity of system specifications. That led us to adopt SysML.

SysML is originally often used to facilitate communication among mechanical, electrical, and software engineers, and within our company as well, it has come to be used for exchanging specifications. We create various diagrams, including block diagrams, activity diagrams, parametric diagrams, requirement diagrams, and many others.

We draw system diagrams in SysML and use them to present specifications to software and mechanical engineers. We also attach state transition diagrams, which software engineers seem to incorporate directly into software specifications.

– Could you tell us about your company's initiatives regarding ISO 26262 functional safety compliance for your QMS and development processes?

Mr. Iida :

While we had opportunities to address functional safety in the past, doing so required significant resources and drive—enough to mobilize the entire company—making it essential to secure actual project orders. It was frustrating when we couldn't win component development orders, but last year a project was officially awarded, enabling us to move forward in earnest.

To achieve compliance with ISO 26262, we are working step-by-step while referencing SPICE documentation to determine how to proceed. I reorganized the team in my section (Powertrain Design Dept., Design Section No. 2) accordingly, and our goal for fiscal year 2018 is to prove that our development process ensures the awarded product can be used with complete peace of mind. Next fiscal year, we plan to advance this further to the point of achieving self-certification.

– What prompted you to adopt safety concept design using "SCDL," and could you explain how you approach it?

Mr. Onishi :

When we had the opportunity to be introduced to GAIO's tools, the topic of functional safety came up, and we were introduced to DNV GL Business Assurance Japan K.K. (hereinafter DNV GL), who provides advisory services. DNV GL explained "safety analysis" and provided an overview of functional safety as a whole.

Ultimately, creating a process compliant with functional safety is necessary, but we determined that mastering safety analysis techniques required for design was the priority. Part 4 of ISO 26262 corresponds to this area, but detailed methods for safety analysis are not explicitly standardized beyond guidelines such as "describe in a semi-formal manner." Unsure of how to actually execute this, we sought advisory support from DNV GL.

Regarding functional safety specifications, we initially tried writing them using SysML, but the results felt unnatural and we couldn't express them effectively. During our advisory sessions, "SCDL" was recommended, so we decided to write functional safety specifications using that method. Since dedicated tools were not available at the time, we drew diagrams and described the connections between functional safety requirements in Excel. However, Excel diagrams are just static pictures, so modifying one part required manually updating all related elements. This was an arduous task that caused us considerable difficulty.

After a while, we were informed that "Safilia" had been released as a dedicated tool for safety concept design, and we decided to try it out immediately. Since the price was reasonable, we were able to purchase it without delay.

– Could you tell us about the functional safety of the shifter and the required ASIL?

Mr. Onishi :

If a product does not have a controlling ECU, compliance with vehicle functional safety is limited, and it is sufficient to consider only a portion of Part 5. However, modern shifters are equipped with controlling ECUs, meaning their control behavior directly impacts the vehicle's functional safety. If the control system behaves unexpectedly, it directly affects the vehicle's behavior, which is why safety goals are assigned. Clients present us with functional safety requirements, which specifically involve the designation of an ASIL level.

There is a significant difference between complying with ASIL-B and ASIL-C. For controls that are even slightly involved in driving, turning, or stopping, ASIL-C or higher may be required. While it depends on the client's intentions, requests for ASIL-C compliance have become increasingly common.

However, for instance, even if the shifter's ECU exhibits a control behavior that suddenly shifts into reverse during high-speed driving, the transmission ECU connected to the shifter is designed to prevent gear changes that would destroy the gears. If such safeguards can be taken into consideration, the safety requirement for the shifter may become ASIL-B.

When ASIL-C is required, our functional safety design process involves performing ASIL decomposition (Note: apportioning ASIL across safety requirements) for the internal controls of our shifters. This is where we utilize the SCDL-compliant tool, "Safilia."

– How has your design process changed since you started using GAIO's "Safilia"?

Mr. Onishi :

Compared to when we tried to describe designs using SysML in the past, I feel that it has become much easier to smoothly draft system safety designs. With SysML, it felt like cramming all the specifications into a single diagram, and partitioning them was a struggle. When using the SCDL-based Safilia, we can easily partition the design content and write it simply, which allows us to clearly express the relationships between each safety requirement. By placing restrictions on inputs and outputs, safety design becomes even easier to handle.

When detailed decomposition progresses and numerous independent requirements emerge, or when examining freedom from interference under Part 4 [of ISO 26262], the requirement diagrams can become large and structurally complex. For this analysis, we use "Safilia" to narrow the scope as we proceed with the design, which helps us create easy-to-understand specification documents.

Specifically, we first narrow the scope of the safety analysis to only the higher-level requirement-related parts. Then, when we move on to examining SMs (Note: Safety Mechanisms), we refocus the scope strictly around the SMs. During the SM examination, we omit everything unrelated to the SM, and adopt a method of adding elements back in later if they become relevant. Finally, to present the overall picture, we merge all the designs to create a single comprehensive diagram.

As a result, I believe our safety design specifications have become remarkably easier to understand compared to when we used SysML.

Our current clients are overseas customers. When presenting our safety concepts, I wouldn't say that SCDL itself is widely adopted among them yet. Despite this situation, we have not experienced any issues with clients not knowing how to read specifications written in the SCDL-based Safilia, and they have been able to correctly understand the contents of our safety designs.

– Could you tell us what benefits you have experienced since you started performing SCDL-compliant safety concept design using Safilia compared to your previous methods?

Mr. Onishi :

When attempting to express a safety concept in SysML, a single diagram is insufficient, necessitating the creation of multiple diagrams. When writing this in SCDL, you can describe the specific events, signals, and constraints within the block diagram structure. I believe this is one of the major advantages of using SCDL. Empirically, if the specifications written in SCDL were instead drawn in SysML, the number of diagrams would nearly double. I think having fewer diagrams has a significant impact on clearly conveying the design content.

We have been using Safilia since its initial release, version R1. As for the advantages of using this tool, since Safilia is purpose-built for safety concept design, it allows us to accomplish tasks quickly with fewer operations. Furthermore, we find it extremely useful that it automatically fits diagrams to the paper size when finally printing them out.

Additionally, being able to export a list of requirements to Excel is highly beneficial. We used to create requirement lists manually, so this has improved our efficiency. With Safilia, simply modifying a diagram automatically updates the linked list, thereby eliminating errors caused by forgotten updates.

Although we have not used it yet, I understand that the newly released Safilia Integrator can generate requirements tables and safety violation tables, so we plan to evaluate it in the future.

– Finally, could you share any requests or feedback you have for GAIO and Safilia?

Safilia is currently still in the realm of a drawing tool; at present, we operate by pasting diagrams created in Safilia into safety requirement specification documents created in Excel. Going forward, rather than just drawing diagrams to illustrate specifications, we hope that Safilia alone will enable us to consolidate all functional safety requirements.

Regarding the editor's internal functions, we wonder if the control of interaction lines could be handled a bit more deftly. In particular, when moving or copying block diagrams, the direction of connected interaction lines becomes disordered and fails to connect in the intended direction, making it time-consuming to correct the lines. We would be grateful if this point could be improved.

Fuji Kiko is a user who introduced Safilia from its initial version and has thoroughly mastered its application. Having engaged in system design using SysML from an early stage, they shared how they swiftly adopted SCDL and have been steadily executing required safety analyses as the transition from mechanical shifters to electronically controlled shifters made functional safety compliance necessary.

GAIO TECHNOLOGY will continue striving for improvements, including addressing the requests received at the end, so that Safilia can serve as a standard tool for safety concept design.

[From the Interviewer]

Fuji Kiko, who participated in this interview, is actively recruiting professionals to join them in establishing functional safety and development processes. Located near Lake Hamana, it is said to be the perfect place for engineers looking to build their careers in a scenic, nature-rich environment.