blog article

BRACE process framework 3.0

Jan. 1, 2017

Jules Breuer

There has been a lot of discussion recently about the huge amount of software that is present in a modern day car Source Some sources claim that a single vehicle might have close to 100 million lines of software code (Approximately 18,000 printed pages)! If so, who is writing all this code!? It certainly is a formidable job for a single person. To make it a simpler task, major automotive OEMs follow the principle of distributed development in which, a huge job is broken into smaller chunks and given to various suppliers. The suppliers successfully realize those chunks. These chunks are sent back to the OEM, who then glues all of them together. Sounds easy right? Well, not exactly! Managing this development requires a lot of effort. That is why processes are heavily used in the automotive industry to manage the development of software.
Process models have quite a history and are being used since time immemorial (Caveman discovering fire was a process too!). In early days, inventors depended on transcripts and letters from fellow inventors to reproduce/improve an invention. These scripts contained procedures that helped them to recreate something that already existed. Slowly but steadily, an increase in the formalization of these procedures was observed. This can be attributed to the automation and mass production of commercially useful inventions. When we narrow down our scope to software and systems, there is a substantial amount of evidence to indicate the existence of processes. For example, there was an attempt to introduce structured programming to develop understandable programs around the 1960s. After an interesting period of development, we now stand at a point where formalization plays a major role in development of software and systems.
Automotive processes: Before going into the automotive processes, let us look at a small example. Everyone loves pizza, right? Right! Now, how do you order a pizza? Simple. You pick up the phone, you order, and the pizza is delivered to your house. That’s all! That’s as simple as a process gets. However, do you know that there is a sophisticated system in place to make this process viable? Take a look below:

Although the process of ordering a pizza seems fairly simple, things get a little more complicated and scaled up when automotive processes are concerned. In order to insert an automotive product into the market, organizations have to follow strict processes to ensure performance, quality and safety of the said product. The product can be anything from an entire vehicle to something as small as a speed sensor. We narrow down our focus towards a particular category of products known as ‘Electrical and Electronic Systems’ (E/E systems). Such systems are increasingly becoming popular to manage the balance between increased functionalities, reduced complexity and reduced development times.

To reduce the development time, big OEMs utilize distributed development. In distributed development, an OEM works with many suppliers to develop individually contained systems such as powertrain, chassis, body, etc. Later on, the OEM integrates these individual units into a vehicle. Such individually developed products are expected to have the following characteristics: Quality, Safety and Security. When all the units required to build a car are produced by the OEM itself, a certain level of uniformity is implied. Since, most of the systems produced today are jointly developed (to reduce development time), uniformity has to be enforced externally. To satisfy these characteristics, there are several standards and process models followed by the organizations in the automotive industry.

As we can see, there are a lot of standards available in the automotive industry. Each category within system development standards has multiple sub-standards. Implementing the concerned standards individually takes up a lot time and mostly results in overhead. A unified and a harmonious process is required for the efficient development of automotive systems. To satisfy this requirement, the BRACE process framework for system development has been developed. As a result, the BRACE process combines the three individual aspects of product development into one unified process. A custom mapping approach is followed which allows us simultaneously compare the tasks and discover the similarities and differences among Automotive SPICE, ISO 26262 and SAE J3061. This allows the elimination of redundant tasks and work products and thereby, reducing development time.

The chart shows an example of a custom framework. Upon this frame work, guidelines from required standards can be imposed to formulate a custom development process. The custom process can then be materialized with the aid of open source tools such as ‘The Eclipse Process Framework’ composer.

With automotive process development, there is no ‘one size fits all’ process that can be widely used by suppliers and OEMs. However, a common framework for establishing processes can be developed. This framework has the possibility to be tailored according to the needs of OEMs and suppliers. At BRACE Automotive we are striving hard just to do that.