NACHI-FUJIKOSHI CORP.

NACHI-FUJIKOSHI CORP.'s Robot Division began initiatives toward functional safety certification for industrial robots around 2004, starting with activities to establish processes and documentation aligned with functional safety certification requirements based on their existing ISO 9001 quality manual. We asked about this background.

– It has been about four years since you first considered our unit testing tool. We understand that initiatives toward IEC 61508 certification were already underway at that time. What was the situation like back then?

– Was that from companies developing industrial robots similar to yours?

Mr. Hamahata :

No, it was from manufacturers in other industries that develop safety equipment. At that time, we did not have much information regarding testing tools, but I recall receiving a recommendation from a manufacturer saying, "There is a tool like this." Since an exhibition (Embedded Systems Development Technology Exhibition) was taking place right around then, we visited GAIO's booth, saw the actual product, and decided to try using it.

– Besides adopting our tools, what other initiatives did you undertake toward IEC 61508 certification?

Mr. Hamahata :

First of all, at that time, we had absolutely no idea where to begin, so we started by consulting with a certification body to verify whether our initial ideas on how to proceed were correct. For example, we already had ISO 9001 quality manuals and standard documentation in place. After reading the original IEC 61508 text, we went to consult with them on what interactions and procedures would be necessary to adapt our existing documentation into a format suitable for functional safety. That is how we began tailoring it into NACHI-FUJIKOSHI's proprietary manual.

– Was a dedicated person working on this full-time, handling interactions with the certification body and other tasks?

Mr. Hamahata :

At first, since we were dealing with areas close to the quality manual, managers took the lead in finalizing the manual. All development stakeholders worked together to identify differences between the overall ISO 9001 quality system and functional safety requirements, as well as what needed to be revised.
While planning how to approach revising the manual, we simultaneously gathered information from manufacturers of safety equipment. At that time, safety networks were becoming popular overseas, and that trend was gaining traction domestically as well, serving as a venue for exchanging information.
We also joined working groups related to safety to collect information. Since safety systems differ from manufacturer to manufacturer, we could not inquire into proprietary details, but we exchanged views at an engineering level regarding what additions were needed and frankly asked how to proceed on topics we were completely unfamiliar with.

– I believe this was about five years ago, but does that mean these initiatives began around 2005?

Mr. Hamahata :

I believe we spent two full years on these activities. Since we started more than a year before purchasing CoverageMaster, we began around 2004 to 2005. At that time, certification was not yet being discussed in domestic safety working groups, but working group activities in Europe were well known, so we even went there to listen and gather information. That was the situation when we started out.

– In the appendices of IEC 61508, there are recommendations regarding techniques or tools to use. Were there any specific items that NACHI-FUJIKOSHI worked on?

Mr. Hamahata :

Since everything was a first for us, instead of asking the certification body "What should we do?", we extracted information by framing questions as "We plan to approach it this way, what do you think?" While the SIL safety level specifications outline many required tasks, we did not execute every single one; rather, we selected items required to satisfy the target safety level and confirmed whether those selected choices were appropriate.

NACHI-FUJIKOSHI CORP.'s Robot Division adopted GAIO's "CoverageMaster winAMS" as their software unit testing tool. We asked them about what prompted them to consider this tool and the key factors behind its adoption.

– How did you proceed regarding the software testing portion?

Mr. Hamahata :

We considered testing fairly late in our activities. Around 2006, when we purchased CoverageMaster, we had already developed a significant portion of the software for the functional safety implementation project. We started thinking about software testing around the stage of writing specifications. Within the standards, there is an initial functional safety requirement specification, where you must describe how safety will be achieved. In this document, we needed to specify, for example, how memory checks would be conducted and how safety would be realized. Later, when creating the test plan, we listed CoverageMaster—adopted as our unit testing tool—and static analysis tools by name.

– In what aspects did CoverageMaster winAMS have an impact on your testing?

Mr. Sugioka :

I think it is the ability to perform tests while rewriting as little source code as possible. Previously, when conducting unit testing for a function, we had to extract the function, build a separate project that calls the function, write code to pass data to arguments, and run the unit test. This required immense effort, so it was a huge advantage that CoverageMaster required almost no effort. By using this tool for the scope of unit testing, we were also able to receive a favorable evaluation from the certification body.

– From a certification perspective, could you tell us how CoverageMaster has been helpful to your company? Feel free to share any changes in awareness on the ground after using it.

Mr. Sugioka :

I believe there was no tool before this that could measure coverage using actual object code in embedded systems. While debugging and verifying on a PC was manageable enough, that was strictly at the PC level and did not reach down to the MCU level. The fact that CoverageMaster realized this was a major key point.
Previously, there might not have been much focus on measuring coverage. However, using CoverageMaster fostered an awareness to ensure coverage completeness—aiming for 100% C0 and as much C1 as possible.

Unit testing using CoverageMaster winAMS had a positive effect not only on achieving certification, but also on improving developers' awareness of quality. We asked how this led to quality improvements.

– So applying CoverageMaster triggered by certification was effective in terms of comprehensively testing code, wasn't it?

– How did you create the unit testing evidence required for certification?

Mr. Sugioka :

We were able to handle it simply by attaching the CSV files of coverage measurement results and input/output test results exported from CoverageMaster as they were. Therefore, no manual work involving major modifications was required.

– Does that mean you performed tests and created reports for all functions?

Mr. Sugioka :

Yes. We created reports for all functions. It turned out to be a substantial stack of paper. Since the scope of certification at that time was only the safety function portion, the scale was about 200 to 300 functions. There were no specific comments from the certification body regarding the report format. Their focus was mainly on verifying that the required tests had been properly conducted.

– After undertaking unit testing triggered by IEC 61508 certification, what proved to be most effective?

Mr. Sugioka :

I think the unit testing initiative was beneficial for evaluating software quality primarily because it produced quantitative results. Having concrete numbers also gave us a sense of accomplishment. We even found several bugs during the testing process.
Designing test cases certainly served as a good opportunity to recheck the source code while reviewing paths and branches. Because we were able to discover bugs while examining the source code as we built test cases, engaging in unit testing prompted by CoverageMaster's application yielded positive results beyond just achieving certification.

– Have you noticed a change in the designers' quality awareness?

Mr. Hamahata :

Indeed, designers' quality awareness has increased. Reading the IEC 61508 standard revealed a wealth of information regarding not only software but also hardware. Rather than viewing these requirements merely as necessary steps for certification, I believe designers have come to see them as methodologies to continue leveraging for evaluating development in the future.
For example, in the case of FMEA (Failure Mode and Effect Analysis), there is an added dimension of considering safety alongside reliability, which I believe positively impacts quality. The same holds true for hardware, not just software.

The product to which functional safety certification was applied this time was a unit designed to ensure the safety of industrial robots on manned production lines. We asked what safety design entails and how it relates to ISO 10218, the safety requirements for robots in industrial environments.

– What was the distribution of man-hours between software and hardware for this certification?

Mr. Hamahata :

Designing for safety for certification is determined by how software and hardware are combined. In terms of man-hours, software design accounts for about 80%, which is extremely vast. As for the testing process, it is probably split about 50/50 between software and hardware. Under IEC 61508, there are tests to evaluate behavior under failure modes. In hardware testing, assuming a component breaks, we methodically remove or disable components one by one; in software terms, I suppose this is similar to ensuring line-by-line coverage.
Safety design for certification is 90% about the initial concept. By that, I mean almost everything is determined by the foundational approach of how safety will be proven. Once that is established, for software, it is just a matter of steadily executing test items using tools like CoverageMaster.

– In the case of industrial robots, safety-related features are likely embedded in both hardware and software. What kind of unit was the target of safety certification this time?

Mr. Hamahata :

Fundamentally, mechanical parts primarily need to be robust, but because they operate across various ranges, safety must be ensured through electronics and software. The functional unit that received IEC 61508 certification this time is the software component responsible for enforcing these operating boundaries.

– Your robots are used not only on unmanned lines, but also on manned production lines, right? I believe there are other standards regarding robot certification for manned lines as well?

The product target for certification this time is intended to add a redundant layer of safety. Standard robots naturally incorporate safety designs, and this unit separately monitors position, speed, and torque to double-check safety on manned lines. Robots have abnormality detection devices installed at each moving part, and while safety is normally maintained through these detectors, this unit further monitors them to ensure safety.

– Finally, returning to CoverageMaster, were there any points of dissatisfaction when using it?

Mr. Hamahata :

If forced to name a complaint, it might be the long execution time when test cases become vast. Originally, we only regarded CoverageMaster as a tool, so we didn't give much thought to its specific features. Ultimately, however, it felt like a perfect fit as a tool for this certification.

– I believe you have shared very valuable insights for companies looking to obtain functional safety certification in the future.
Thank you very much for your cooperation.

In this interview with NACHI-FUJIKOSHI, we were able to learn about their various initiatives and innovations for achieving both high reliability and safety. They noted that CoverageMaster successfully met their needs by enabling reliable unit testing when complying with functional safety standards.

GAIO TECHNOLOGY will continue to provide optimal tools and solutions to reliably support our customers in complying with functional safety standards. (GAIO TECHNOLOGY Sales Dept.)