Clear definitions for complex requirement profiles
Stuttgart, Nov 30, 2006
Vehicle electrical and electronic systems are not only becoming more comprehensive; they’re also growing increasingly complex, especially in terms of their functions. This development is being driven by automakers’ ability to precisely define which requirements a certain component must meet in order to ensure that it can subsequently be integrated as desired into the overall system. For a component or system to even be suitable for cross-platform applications, a very sophisticated approach is needed — a new culture of vehicle development that demands more than simply specifying technical processes.
Anyone who thinks a blinker is only a simple light, or says that a tachometer can hardly be considered a complex instrument, can expect a vociferous rebuttal from Frank Houdek. The DaimlerChrysler researcher needs only a few minutes to convince even the most uninformed lay person that such notions are all wrong. “I myself am time and again amazed by how complex the definitions of requirements have to be, even for components I had thought were very simple,” he reassures his novice visitor.
Houdek works in the Software Process Design department led by Bärbel Hörger in Ulm. The sign on his office door says “Requirement Engineering Processes,” because there’s no succinct German translation for this area of research. The focuses of the work performed by Hörger’s department include a process central to the overall task of vehicle development — specification. To the experts, the term means precisely describing all the requirements that must be fulfilled by simple components like LEDs, by more complex systems such as the vehicle dynamics system ESP, or even by the entire vehicle with all of its various functions.
And in this field, “precise” means “unambiguous.” In practice, “unambiguous” in turn means that “Anton,” a development engineer responsible for a control unit, is able to understand a requirement definition in exactly the same way as does his colleague “Boris,” whose tire pressure sensor sends a signal to Anton’s component. And the two of them must understand the specification document in exactly the same way as “Claude,” an engineer working for a supplier who is responsible for developing the tire pressure display for the instrument cluster of the planned model.
Clarity also means that development engineers “Osamu” at Fuso in Tokyo, “Beth” at Freightliner in Portland and “Kurt” at Mercedes-Benz in Stuttgart all have exactly the same understanding of a jointly formulated requirement definition — for a new multifunctional display that is to be installed in the respective instrument clusters of the heavy-duty trucks from these three brands, for example.
> Identical parts for multiple applications reduce unit costs
For the first time, Fuso and Mercedes-Benz have jointly developed a vehicle platform for a new product family of trucks — “SFTP,” which is to include a number of identical parts suitable for cross-brand applications. Higher production volumes mean lower unit costs. That’s why the aim is to use economies of scale to achieve very high efficiency in the production of components like the instrument cluster that Osamu, Beth and Kurt must adapt to the requirements of their respective brands.
The document with the requirement definitions for the SFTP instrument cluster is the size of a telephone book: It contains roughly 1,000 pages of text, tables and illustrations. That’s not all: It’s supplemented by about 100 “accompanying documents.” These papers cover all of the norms, external ones as well as each company’s own standards, that the developers of the instrument cluster must satisfy, or they describe with painstaking precision the testing procedures that the component must be subjected to. “All in all, there are at least 5,000 pages of text still to be added,” says Houdek.
The critical factor isn’t the impressive scope of this documentation, however. More important is achieving a consensus among everyone involved in the process of creating such a specification, and ensuring that the document is written in a manner that they all will interpret in the same way. And, as in the case of the instrument cluster, that can mean more than 100 people, who are also working on three continents. The young American Beth, for example, may be more familiar with the latest work methods than Kurt, who completed his training as an electrical engineer more than 20 years ago. And development work at Fuso may very well call for different routines and processes than those used in Portland or Stuttgart.
> Increasing complexity means more requirements
The overall complexity of the object under development raises the bar even higher: “Practically every system in the vehicle should be able to display some values or information in the instrument cluster,” explains Houdek. Data and signals from throughout the vehicle converge at the instrument cluster, for example. Here they are converted into appropriate displays of information, and other signals conveying the driver’s commands are sent to the corresponding vehicle components. And all of this must happen while ensuring that the signals don’t interfere with one another and that the stream of signals always flows in a correctly prioritized sequence and at a sufficiently high speed.
“At first, such complex developments caused malfunctions and errors in the software development, because requirements weren’t defined with sufficient precision,” explains Houdek. That’s why the IT industry played a pioneering role in creating precisely formulated specifications. With the increasing complexity of electrical and electronic systems in vehicles, the specification process also very quickly became a key factor in assuring quality in this field of engineering. Meanwhile, it also is becoming more important in the development of purely mechanical components.”
Bärbel Hörger’s department began very early on to find ways to improve software processes, which is why it attracted more and more customers in vehicle development. In a variety of pilot projects, Hörger’s colleagues analyzed how development teams had generated their specifications, and also studied the weaknesses of these documents. In cooperation with the developers, the researchers in Ulm then created a process that resulted in a clearly defined specification document.
Given today’s distribution of development work — with Osamu, Beth and Kurt simultaneously developing a component while scattered across three continents, for example — such a precise document is a must. Despite the Internet and telephones, however, developers working in different time zones can’t always quickly resolve questions. This is why a continually updated document containing all of the requirement definitions serves as a point of reference that’s always accessible to everyone.
> Greater emphasis on users’ needs in the future
Additional elements for improving quality also should be integrated into the redesign of processes, a task for which Hörger’s department serves as a kind of “midwife.” “Let’s imagine what would happen if we asked a technician and a lay person to describe the same navigation device,” says Hörger. The two texts would be very different, that’s for sure: One would precisely list items such as input impedance, signal qualities and storage capacities, and the layman would submit wishes like “ease of use,” “no more bothersome typing in of destinations” or “device should notify drivers of filling stations on the route with the lowest fuel prices.” The specification document should include not only purely technical definitions, but also such user- or function-oriented requirements of drivers. The fact is that customers want more than just a perfectly functioning device. They also want one that’s enjoyable and easy to use, and that offers genuinely useful functions. Such functions — known as “use cases” — are therefore immediately added to the catalogue of requirements.
But this main document must define more than just the technical and functional requirements. It also must address ecological aspects, for example how easily a product can be recycled, and questions regarding its service life and quality. Hörger puts it in a nutshell: “What good is a vehicle’s flashiest feature if it continually causes malfunctions or even failures?” Such defects don’t just annoy customers; for aftersales departments, they also result in additional costs for warranty and ex gratia services. “The specification process is where completely conflicting requirements collide,” explains Hörger. It isn’t always easy to ensure high quality at the lowest possible costs, or to reconcile users’ wishes with the limits of technologies.
This is why supervising a specification process requires not only solid expertise in engineering but also a generous measure of the human touch. When faced with conflicting interests, how do you reach a compromise, or finally a consensus, which everyone really accepts? What are the most efficient and streamlined ways to coordinate the agreement and approval processes carried out by so many participants? Have the requirements been correctly prioritized? “Supervision also involves what are known as ‘soft’ factors, and our experience shows that women engineers excel in handling this process,” says Bärbel Hörger, who is helping to make this area of activity a women’s domain in the still male-dominated world of engineering.
> From successful individual projects to widespread use
In 1998, Hörger’s department began to provide support for E/E engineers in individual development projects by moderating specification processes and adapting the processes to the requirements of the respective project teams. “You can’t just create such a process from a blank slate and implement it by means of an impersonal command from on high,” warns Hörger. And her approach also works both ways. “We have worked with small teams of developers, showing them solutions that they could use to achieve demonstrably improved results. And you would be amazed at how fast word of this gets around within a department or a center,” she says.
In the meantime, Hörger estimates, the new specification process is being used for about half of all E/E development projects. Based on the clearly more dynamic development that has resulted, the software specialist forecasts that practically all E/E projects will be using this approach in three to four years.
> Development between Scylla and Charybdis
Just as in Homer’s Odyssey, in which Odysseus and his crew had to pass through a strait flanked by the lurking sea monsters Scylla and Charybdis, the specification process requires a team of developers to navigate a safe course between two dangers: While necessary requirements mustn’t be overlooked, it’s also important to ensure that unnecessary requirements don’t make their way into the document.
Too few requirements are just as bad as too many
If a necessary definition is overlooked, the inevitable consequence is additional costs. For example, a supplier is assigned the task of developing a display for a tire pressure control. The team that formulated the specifications thought of everything — except the data format of the signal that controls the display. The supplier’s display uses a 16-bit signal transmitted by a sensor, but the control unit that sends the signal to the display sends 8-bit data packets. The result is a costly and time-consuming adjustment.
But “over-regulating” also has its pitfalls. “Predetermined solutions ignore the supplier’s expertise,” explains Frank Houdek of the Software Process Design department. What is crucial is to define everything that’s desired — without dictating how to implement it. In practice, this means the specification should be less oriented toward a precisely predetermined hardware; instead, it should be geared toward the functionality of an individual component or an entire system.
“The supplier’s creativity, in particular with regard to how the company implements a certain function, is an important criterion when awarding a development contract,” adds Houdek. “Although,” he admits, “it’s very difficult to know exactly where to draw the line in any individual case.” That’s why this difficult challenge is also an important part of the specification process, in which all participants, for example, must very precisely coordinate where their respective tasks begin and end, while freely sharing their expectations with one another.
Communication instead of assumptions made in isolation In the scenario cited above, the supplier’s engineer assumed that the control unit to be used would “almost certainly” work with 16-bit coding, while the developer of the control unit was told that “we always supply the signals with 8-bit coding” by the colleagues responsible for the sensors.