Autosar standards open the door to auto design optimization, Part 1

(Editor's note: This is the first of a two-part series of articles describing the emerging Autosar (Automotive Open System Architecture) automotive design standard. Part One discusses Autosar's origins and architecture along with an analysis of its key features.)

The emerging Autosar automotive design software standard began as the product of an industry-wide effort among European auto makers and their suppliers. Its objectives are similar to those of software standards in other industries: to bring structure, clean interfaces and implicit methodologies to a process—in this case, the design of distributed systems within automobiles.

What do these lofty aspirations mean to the designer who needs to get a complex array of automotive functions working together with high reliability? To the executive responsible for minimizing costs while delivering timely products to customers? To the end-users of tomorrow's automobiles?

Clearly the automobile industry is in transition. Government regulators, if not auto buyers, are pushing for smaller, cleaner cars—an evolving imperative that equates to man-years of engineering time spent on research and development. Add to this, the burden of electrical and electronic distribution, growing more complex with each new feature that either regulators or consumers demand. And, of course, there is unending pressure to improve reliability and expand design flexibility while reducing development costs.

Never has there been a better time to adopt technologies that can simplify the designer's job and streamline the end products that embody his or her work. Autosar is such a technology.

It represents a set of standards encompassing interfaces and software module definitions. Most importantly, it sets forth a structure for the embedded software that ultimately operates a vehicle's complex network-based distributed system. At the conceptual level, Autosar can be viewed as a new platform that enables designers to focus on innovative functions while insulating them from the implementation details of integration.

In this context, vehicle "functions" include climate control, transmission control, anti-lock braking, suspension, and many others both large and small. They encompass every subsystem that must interact with either the vehicle's human operator and occupants or its other electrical and electronic subsystems. Today these features operate under the control of a phalanx of single-function electronic control units (ECUs).

For Autosar, things are different. Functions consist of one or many software components (SWC) that can be executed on any Autosar-compliant ECU. The controls implement differentiated features in the end product. Compare this approach with an existing architecture made up of single-purpose ECUs. In the older approach, each ECU is associated with a fixed software definition. It is custom-programmed and hard-wired for one specific task. In contrast, an Autosar-compliant ECU is an uncommitted "dock" for software components whose functions define the ECU's role in the vehicle's operation.

Given two outwardly identical hardware modules, one may run the climate control system while its twin runs the dashboard functions.

Autosar SWCs interact via an application programming interface (API) known as the Autosar Runtime Environment, which fronts underlying mechanisms that carry out computation, control and communication activities. Figure 1 depicts a simplified overview of this model as it appears within a compliant ECU.

Figure 1: An Autosar-compliant ECU loaded with standardized general-purpose software stacks that interact with SWCs to implement vehicle features Click on image to enlarge.

The lower tier is essentially "generic" while the upper tier of SWCs is given over to design innovation. What is the implication of this dichotomy? While today's typical car has 20 or more different ECUs, Autosar may shrink this total to just a few different ECU types whose behavior is determined by application content.

These types will occupy a hierarchy of performance that matches the jobs they will do. For example, a low-cost 4-bit ECU might suffice for door locks and window controls, while a 32-bit unit with large memory capacity would be needed to execute real-time power train management duties. While the car may still house 20-plus ECUs, there might be just four or five different hardware types.

While the ultimate vision is in the initial adoption stages, the spec has the potential to significantly change the relationship between the subsystems in a car. And it could change the face of automobile architecture and design as well.

Enabling new approaches to auto design, production

If that latter statement seems like a grand claim, contrast traditional automotive system design with the Autosar approach. Most auto brands are actually OEMs— known in other industries as "integrators"—that design vehicles and assemble them from components bought from tiers of contracted suppliers. One supplier might deliver the anti-lock brake system, another the climate controls. These functions are completely self-contained in that they include all the mechanical, electrical, electronic and software ingredients required to implement a function.

It is a business model that makes it difficult and expensive for OEMs to change any aspect of a design after signing off an order with the contractor. Even a modest software change requires a new request for proposal, with all the attendant time and cost. With market economics pressuring car makers from one direction and exploding complexity pushing them from the other, much more flexibility is needed.