The emerging Autosar automotive designsoftware standard began as the product of anindustry-wide effort among European automakers and their suppliers. Its objectivesare similar to those of software standardsin other industries: to bring structure,clean interfaces and implicit methodologiesto a process—in this case, the design ofdistributed systems within automobiles.
What do these lofty aspirations mean to thedesigner who needs to get a complex array ofautomotive functions working together withhigh reliability? To the executiveresponsible for minimizing costs whiledelivering timely products to customers? Tothe end-users of tomorrow's automobiles?
Clearly the automobile industry is intransition. Government regulators, if notauto buyers, are pushing for smaller,cleaner cars—an evolving imperativethat equates to man-years of engineeringtime spent on research and development.
Addto this, the burden of electrical andelectronic distribution, growing morecomplex with each new feature that eitherregulators or consumers demand. And, ofcourse, there is unending pressure toimprove reliability and expand designflexibility while reducing developmentcosts.
Never has there been a better time to adopttechnologies that can simplify thedesigner's job and streamline the endproducts that embody his or her work.Autosar is such a technology.
It represents a set of standardsencompassing interfaces and software moduledefinitions. Most importantly, it sets fortha structure for the embedded software thatultimately operates a vehicle's complexnetwork-based distributed system. At theconceptual level, Autosar can be viewed as anew platform that enables designers to focuson innovative functions while insulatingthem from the implementation details ofintegration.
In this context, vehicle “functions” includeclimate control, transmission control,anti-lock braking, suspension, and manyothers both large and small. They encompassevery subsystem that must interact witheither the vehicle's human operator andoccupants or its other electrical andelectronic subsystems. Today these featuresoperate under the control of a phalanx ofsingle-function electronic control units(ECUs).
For Autosar, things are different.Functions consist of one or many softwarecomponents (SWC) that can be executed on anyAutosar-compliant ECU. The controlsimplement differentiated features in the endproduct.
Compare this approach with anexisting architecture made up ofsingle-purpose ECUs. In the older approach,each ECU is associated with a fixed softwaredefinition. It is custom-programmed andhard-wired for one specific task. Incontrast, an Autosar-compliant ECU is anuncommitted “dock” for software componentswhose functions define the ECU's role in thevehicle's operation.
Given two outwardly identical hardwaremodules, one may run the climate controlsystem while its twin runs the dashboardfunctions.
Autosar SWCs interact via an applicationprogramming interface (API) known as theAutosar Runtime Environment, which frontsunderlying mechanisms that carry outcomputation, control and communicationactivities. Figure 1 depicts asimplified overview of this model as itappears within a compliant ECU.
Figure 1: An Autosar-compliant ECU loaded with standardized general-purpose software stacks that interact with SWCs to implement vehicle
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.
Therein lies a key benefit of the Autosar: it allows OEMs to recapture a greater degree of control over the architecture of their vehicles. Assuming existence of a diverse market in compliant components, an OEM can simply order the elements and standardized ECUs for, say, a suspension package from a specialty supplier. The OEM's design team then adds intellectual property in the form of the software components (applications) that make the suspension system deliver the comfort, safety and responsiveness that distinguish the car's brand.
Opening the door to optimization
At this point, I contend that its clear that Autosar offers some direct efficiencies and economies that can be of great value to auto makers. But the flexibility of its SWCs concept promises other benefits that may pay even greater dividends in the long run:
1. There is no firm rule that says one ECU must contain all of the SWCs associated with a particular function. Every ECU contains the same standard interface (namely, the Autosar RTE) that can execute SWC code regardless of its role in the vehicle.
2. Many ECUs have some computing bandwidth to spare. Even in a world that demands efficient use of every internal computing resource, some ECUs will very likely have room for a few more SWCs.
Taken together, these two simple facts open the door to an optimization approach that can could dramatically reduce the total number of ECUs required to operate an automobile. If a function such as cabin lighting requires five SWCs, for example, three of those might reside in the local ECU allocated for that job, while the remaining two reside in a nearby ECU that manages dashboard displays. Optimization can reduce complexity, save space and reduce cost, simplify wiring harness development and improve reliability. In theory optimization will allow designers to configure vehicles with the fewest possible ECUs and the least complex wiring.
But will it work?
Optimization must be pragmatic, and pure simplification can't be its only goal. Consider this working definition of optimization:
“Optimization: manipulating a particular system's state such that it achieves a new, improved state that is better by objective metrics .”
These metrics reflect the goals of the design project, which typically encompass not only simplicity but also cost, performance, functional priorities and many other issues. It might seem cost-effective to use a brake system ECU's spare capacity to support the air conditioner controls, but that risks compromising the braking response at a critical moment, and might even add cost to other components such as the wiring harness. In the real world, extensive analysis must be applied in conjunction with optimization.
To be a candidate for optimization, a system must have certain properties: an initial state that is easy to describe to computer software; variables that are easy to manipulate; and outcomes that are easy to observe and compare as they evolve.
Knowledge of the initial system states is key to the entire process. Until now there has been no uniform way to characterize the state of an automotive system. Terms like “quality” and “efficiency” apply, but they can be rather intangible and subjective.
Traditional (pre-Autosar) optimization has relied on the engineer's experience and intuition, conditioned by time, cost and legacy constraints. But the increasing number of variables (even if the consideration is limited to ECUs alone) geometrically multiplies the number of solutions that must be evaluated. The scale of the optimization space soon exceeds the grasp of human faculties.
Autosar introduces discipline in the form of a language that allows designers to concretely represent a distributed system, manipulate it and then assess the result. Autosar's XML files are declarative files that comply with Autosar formats and enable designers to describe systems, ECUs, SWCs, mapping, timing and more. A climate control system, for example, might be fully defined by a dozen files relating to its overall functional behaviors.
In Autosar-based design, as in other creative efforts, the starting point or initial state is frequently a modified predecessor design that incorporates new features proposed by the architecture team. This “device” usually includes some intuitive SWC/ECU mappings which may or may not be usable as the design evolves.
Optimization is based on analysis, of course. There are two ways to approach analysis: static and dynamic. The former is more simplistic and more common at present.
In static analysis, the solution might begin with system representation that symbolizes a group of SWCs mapped to ECUs. The question to be answered is straightforward: Is this configuration good or bad? Is it appropriate to put all of the climate control functions, for example, into single ECU?
An Autosar-based analysis tool can provide pragmatic answers because:
It is important to note that static analysis still isn't an optimization procedure. But its findings can drive the optimization steps, and it allows the design team to develop and test basic configurations easily. A static analysis confirms that, yes, module “A” can receive and process packet “B” and, furthermore, that packet “B” is of an appropriate type.
The next increase in capability is called dynamic analysis. This approach incorporates simulation. Dynamic analysis begins with the construction of a set of software-based models embodying the best approximation the system elements' behavior. The object is to force the models to do just what a complex hardware/software combination would do.
Dynamic analysis brings the dimension of time into the evaluation. It might reveal, for example, that identical packets “C” and “D” arrive at the same time as packet “B,” and the module has no way to deal with these three events at once. Dynamic analysis is a more rigorous and realistic test of a design.
This article was previously published on EETimes.