Standards Step Forward in Design of Off-highway Electronics

Functional safety standards are starting to impact many development projects, while the auto industry’s AUTOSAR standard is being deployed to help enable software reuse and simplify designs.

October 1, 2015

Terry Costlow

Even memory chips in the control modules for Dana’s transmissions are selected with safety standards in mind.

Functional safety has become a watchword in many fields as regulators and product developers attempt to ensure that failures will be minimal, and that safety isn’t impaired when things do fail. ISO 26262 was developed for the automotive industry, and other standards like IEC 61508 are required in some fields.

On another front, the AUTomotive Open System ARchitecture (AUTOSAR) is slowly gaining acceptance. It shifts software development to a function-based system design, which helps companies manage the growing complexity of electronics by creating standard interfaces between hardware and software components.

Safety first

European safety standards are having an impact in the U.S., according to Eaton’s Brenner.

Some regulations already require compliance with functional safety standards, and more legislation is set to follow suit. That’s prompted many companies to make these concepts part of their design methodologies. Implementing risk assessment and other functional safety ideas is no small task.

“We have a whole department dedicated to checking safety standards,” said Steven Dumoulin, Team Leader for Controls at Dana Holding Corp. “It’s a huge job that has an impact from the highest to the lowest levels. Even memory, flash and RAM, has to have memory checks.”

Complying with the standard requires some changes to the design process, forcing developers to consider potential safety issues and remediate them. Additional hardware and code are needed to provide redundancy and diagnostics. Many companies say the extra elements will become the norm.

“ECUs are becoming more complex and costly as additional processors are required to monitor or work in conjunction with the existing application processor,” said Paul Brenner, Marketing Manager, Electronic Controls & Software and Mobile Piston Portfolio, Eaton. “The European Machinery Directive 2006/42/EC requires compliance for machines sold within the EU. The trend is spreading to North America because companies don’t want to manufacture multiple models for different regions.”

More customers are asking Parker to design ECUs to meet safety integrity level requirements.

Providing some level of redundancy while avoiding the high cost of dual everything is a key challenge. Multiple chips must monitor each other, adding communication and processing overhead.

“Functional safety increases code size and CPU requirements just as if you added more functions,” said Jason McConnell, Business Unit Director, Electrification & Hybrid, IAV Automotive Engineering. “You need some hardware to communicate and serve as a watchdog, which drive more requirements for memory and clock cycles. This watchdog can be a smaller microprocessor or a small ASIC [application-specific integrated circuit]. There are specific chips designed to be watchdogs.”

Though compliance must come at the system level, many suppliers are certifying their components and subsystems to make life easier for OEMs.

“The advent of Safety Integrity Level 2, or SIL2, controllers are being specified by more customers looking for SIL compliance,” said Kirk Lola, Business Development Manager at Parker Hannifin Electronic Controls Division. “This allows the machine designer to use the certification and the reliability data for a certified controller to help design a SIL-compliant machine.”

Observers note that none of these functional safety standards were written for off-highway vehicles. That makes meeting the sometimes vague requirements written by committees even more difficult.

“In the U.S., we haven’t seen functional safety requirements like we have in Europe,” said Dave Rogers, Ricardo’s Commercial Director for Engines. “Things are carried over from automotive, but a lot of requirements in off-highway don’t exist in automotive, things like power takeoffs.”

Simplifying software

Off-highway equipment developers are tracking another automotive trend, adopting the AUTOSAR standard. Now roughly a decade old, it provides a common structure for basic system functions and functional interfaces, letting teams focus on higher level applications instead of interfaces.

Only large OEMs are investing in AUTOSAR, said TTControls’ Weissengruber.

“AUTOSAR provides a convenient way to compartmentalize pieces of software,” said Tom Tasky, Manager of Controls and Functional Safety, FEV. “Using a standardized interface lets you reduce size and ensure that software is portable. Our software platform is built on the foundations of AUTOSAR. We can adapt if customers are not using fully compatible versions.”

Implementing a new software architecture isn’t an easy task, so AUTOSAR won’t be showing up for a while. Though many companies are employing limited aspects of the standard, they still expect to gain meaningful benefits.

“Almost all of our early development work for ECU in the 2019-2020 timeframe have some level of AUTOSAR requirements,” said IAV’s McConnell. “Legacy technology is a challenge, but using this software architecture as part of a development enables you to have better control over the system life cycle. AUTOSAR lets software reuse happen.”

Not so fast

While standards bring many benefits, vehicle manufacturers are often slow to adopt them. It’s often time consuming and expensive to devise a transitional strategy.

“In the off-highway industry, only the very big OEMs are investigating the use of AUTOSAR,” said Marc Weissengruber, Product Marketing Manager, TTControl. “For small and mid-size OEMs, the effort and cost is currently too high compared to the benefit.”

Others note that the need to maintain proven software prevents many companies from adopting the standard. However, some ideas used in AUTOSAR are being used in conjunction with legacy programs.

“Everyone has something they’re already using, so unless they’re going to a fully new software platform, it’s difficult to use AUTOSAR,” Ricardo’s Rogers said. “There’s piecemeal usage, people take part of it and create software abstraction layers. They create a big map for variables, it acts like a big library that lets one module play with another.”

Tier 1s who must implement the standard for large OEMs are implementing it throughout their new designs. Many companies are using their own versions rather than spending time to develop fully compliant technologies, feeling that the concepts bring significant benefits.

“Reuse is the reason we started exploring AUTOSAR,” said Dana’s Dumoulin. “We didn’t want to rewrite software over and over. We now have proven software that’s reusable across platforms. Its structured approach also improves maintainability, when a change is requested, we can easily see whether it can be done and what the impact will be.”

The structured approach required by the standard also helps companies comply with safety regulations that are rapidly altering the industry. These standards must be considered from the outset of a project, so they are often complementary.

“Using an AUTOSAR framework helps us comply with functional safety standards like ISO 26262,” FEV’s Tasky said. “Functional safety has a huge impact on hardware and software development, customers need to understand their safety requirements early in the concept phase.”