Dear reader
For the SW-defined car, the integration of complex systems is key. Engineering must come together, notably mechanics and electronics, the latter of which is increasingly moving towards new software architectures. As the solutions become more complex, so too do the requirements in terms of system integration. Traditional approaches are no longer fit for purpose or must be expanded to accommodate additional requirements.
One very promising solution is systems engineering. This methodology combines both the process and product perspectives as part of an integrated development approach. It enables users to manage their work more transparently, especially when combined with our Automotive integrated Development (AiD) blueprint, which we introduced in the last edition of Concepts. AiD joins forces with systems engineering methodologies for a complete Automotive Systems Engineering approach, which identifies all functional and non-functional requirements and ensures each task is scheduled and all dependencies are transparent.
//Automotive Systems Engineering
So far so good, but integration is not just a macro-level requirement; additional steps in this direction are also needed within each individual engineering domain. A good example of this can be found in software engineering. Traditionally, developers program every individual task that the software performs. But Machine Learning (ML) has changed all that. Instead, tasks are described in abstract terms and learning algorithms trained to perform them. In other words, the software writes itself. Traditional approaches to software engineering now need to be adapted to accommodate and validate software artifacts generated by ML. Read on for our interview with our Machine Learning Engineering experts to find out more.
Open source software is a potentially valuable tool in developing the complex solutions required by connected cars. Will the new up-and-coming vehicle architectures see OS used more widely? To find out the answer to this fascinating question, we surveyed a group of experts. You can read the results in our industry barometer report Automotive FLOSS. State of Practice 2021.
//More on FLOSS
Integration can feel like a juggling act. But don’t worry. To help your team leads keep all the different balls up in the air, we’re currently developing an intensive training program in Automotive Systems Engineering.
We hope you enjoy reading this edition!
The Concept Crew at Kugler Maag Cie
Advanced Automotive Systems Engineering
Advanced Automotive Systems Engineering combines product, process and methods: Together with the AiD blueprint, the integration of all stakeholder perspectives results in a complete R&D blueprint for the software-defined car.
Views in the field of Systems Engineering
Automobile manufacturers rightly call themselves systems integrators: They specify requirements for their supply chain and integrate the components supplied into the overall vehicle system step by step. The in-car connectivity shifts the focus of functionalities to the software level. Systems integration acquires a new meaning as a result – it is all about mastering numerous microservices within in a server-like software architecture in combination »with mastering the interface between mechanics and electronics« as a core competence, as Christian Hübscher, Principal at Kugler Maag Cie, points out.
Connectivity additionally means that the vehicle systems communicate with other systems and interact within one large system. The functionality of the networked system reveals itself as the individual systems interact; system behavior is highly dynamic. The vehicle system must therefore be designed to deliver the desired functions within this system environment. For those involved in development, this means a dramatic shift in the system boundary – isolated embedded systems are a thing of the past.
»Mastering the interface between mechanics and electronics becomes a core competence.«
Christian Hübscher, Principal at Kugler Maag Cie
First Time Right
More than ever before, short market cycles and increasing complexity demand a first-time-right approach – requiring a methodology that supports the close interaction of all parties involved in the fields of mechanics, electrics/electronics, systems engineering and software engineering. To be able to further develop the manufacturers’ integration competence in a dynamic connected system landscape, a comprehensive understanding of the system is just as necessary as a coordinated approach among those involved in all engineering disciplines, including suppliers.
No wonder that more and more automotive industry managers are becoming interested in systems engineering. SE combines the product perspective with a structured approach, both in terms of workflows and goal-oriented methods. By interlinking these perspectives, systems engineering coordinates development and helps to safely manage complexity – this is a prerequisite for integrating the services provided by the numerous project participants to achieve operability.
SE consistently connects the perspectives
- of the system to be developed
- the processes to be applied, and
- of the supporting methods and practices
Systems Engineering across the product lifetime
Systems engineering was originally developed in the late 1960s in response to the so-called software crisis. In the days of mainframe computers, hardware power increased massively, and the skills of software developers could not keep pace. Computer science was more a craft than a science. As a result, there was a lack of project management experience to cope with the increasingly complex application development. This deficit was particularly noticeable in the defense industry: Here, the need for functional improvements through mechatronics was faster than in other industries. Ecosystems of suppliers gradually developed around these manufacturers, in different constellations depending on the mission. SE is a response to this challenge of purposefully developing and integrating systems in a self-directed ecosystem.
Today, the automotive industry faces a similar challenge: Monolithic vehicle architectures with countless electronic control units (ECU) are being replaced by domain control units (DCU). The vehicle architecture is evolving toward a software-defined architecture with a powerful in-vehicle server at its core. Hence, manufacturers are increasingly tending to build up software expertise, traditional supply chains are disappearing in favor of more dynamic ecosystems. An experience which the defense industry has already been through. The automotive industry therefore has an opportunity to learn from these and other industries.
No ready-to-use approach
However, systems engineering also benefited from experience in the automotive industry, especially from software development: Findings from the application of process models and tools were channeled into the ongoing development of systems engineering and integrated into the body of the method. Systems engineering, which used to be a rather theoretical discipline, learnt a great deal from industrial practice as a result.
Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.
Definition by INCOSE
Systems engineering is thus a problem-solving process, not a ready-to-use approach. Accordingly, vehicle manufacturers can – and must – adapt the process to their needs. This obviously also includes incorporating normative requirements such as cybersecurity, functional safety and Automotive SPICE.
As a comprehensive engineering activity for efficient and methodical-structured electronics development, systems engineering focuses primarily on system design through
- system analysis,
- definition and management of requirements,
- system architecture design,
- system simulation and development,
- validation and test phase.
These aspects are central to a comprehensive – and shared – understanding of the system across the entire development process. Because systems engineering thrives on consistency, from the design of a system through to the operational phase. Precisely because new architectures such as the software-defined vehicle demand interdisciplinary development teams, a common, or at least consolidated, understanding is essential. To achieve this system thinking, SE focuses on the aforementioned key areas, especially during structured project setup, because this is where the course is set for the success of the project.
Core Aspects of Systems Engineering (Fraunhofer IPK, 2013)
At the beginning there is a system model
In contrast to the process models found in electronics development, the consistent integration of the product view is new in SE. A system model is used for this purpose, via which all essential information is communicated, including functional and non-functional requirements. To create the model, the target system is described in its entirety, in uniform style for all stakeholders and project participants. The individual perspectives are linked to the system model.
Representation options are
- diagrams for a graphic presentation
- repositories as data models for system modeling
The difference: In a repository, the data are consistent, because they occur once only. Diagrams can be used to present stakeholders with the information relevant to them. Management perspectives can be distinguished from engineering perspectives, for example.
Model-based systems engineering (see box) goes a step further. In MBSE, the system model is even the focal point of development. This virtualizes the development process and forms the basis for communication between the project teams of the various disciplines and the management. For this purpose, the model describes the system in a domain-independent way and includes all central information. This information is dynamically available and up-to-date. Stakeholders use a modeling language, e.g. SysML, and a uniform software tool.
The model ensures horizontal and vertical consistency. Virtual verification and validation of the vehicle can be another goal. Contractors can show the client in which phase each component is, outcomes can be stored here. Modeling makes sense from the automotive perspective: Due to functional safety and cybersecurity, more and more non-functional requirements have to be allocated to the architecture. A model can support documentation for a safety-and-security-by-design approach.
From head to toe
The system model as a pivotal point makes it clear that SE is a deductive process: as in the natural sciences, sub-tasks are derived from the overall model. Downstream engineering starts from the model as a target catalogue and ensures continuity and consistency down to the individual parts. SE provides the development logic to all stakeholders: How should the requirements be understood in specific terms, to which goals should they be broken down? Definition of done criteria can also be accessed and verified here.
In the run-up to the project, the deductive top-down approach can be followed by an agile project setup. This is because SE encourages a multi-perspective approach which also includes experimental thinking in variants. SE then becomes, as with early agile approaches, a problem-solving cycle which thinks from the end but allows a flexible path to implementation – the product creation process occurs as a step-by-step refinement along interlocking phases.
As there is no general business case for the application of SE, one must first be determined for each project: One must ask whether this approach will deliver the desired results and whether the effort is justified. In automotive electronics, new developments in vehicle or platform architectures lend themselves to this integrated-structured approach. An argumentative hurdle for the use of comparable process models is having to convince the management. Because profitability can only be measured at the end of the business cycle.
To be able to train system competence for the target system, systems engineering focuses on identifying, defining and documenting system requirements in the conception phase. At top left in the Vee-model of SE, the Concept of Operations is used for this purpose. In ConOps, the system to be developed is described abstractly from the user’s perspective: key concepts, capabilities, the deployment environment, etc. At this level, the product vision is conveyed and the selection of the participating internal and external service providers is supported. ConOps summarizes the business and mission analysis and describes the integration with higher systems. It forms the basis for the identification of requirements and influences architecture-related decisions.
The so-called Heilmeier Catechism can provide impetus for this task. The Catechism formulates a set of questions which officials at the U.S. Defense Advanced Research Projects Agency (DARPA) are supposed to keep in mind when evaluating research projects:
- What are you trying to do? Articulate your objectives using absolutely no jargon.
- How is it done today, and what are the limits of current practice?
- What is new in your approach and why do you think it will be successful?
- Who cares? If you are successful, what difference will it make?
- What are the risks?
- How much will it cost?
- How long will it take?
- What are the mid-term and final exams to check for success?
Following the logic of downstream engineering, the ConOps is later broken down to an OpsCon. To be able to concretize this, specifications are derived from the abstract description. It should be formulated how the use cases are to be implemented, in particular how the interaction between the components, as well as the people with the system, are to be designed. Both concepts, ConOps and OpsCon, clearly show what SE is aiming at: to render stakeholder assumptions explicit and visible.
Important for the connected vehicle: the SE concept papers also bring the future into play, especially maintainability in the operational phase. For example, what good are DevOps teams for digital micro-services if the vehicle architecture is not designed to be maintenance-friendly or not scalable? Downstream tasks are becoming increasingly important in the connected vehicle. Nevertheless, investment in new projects continues to dominate the culture in development departments – CapEx trumps OpEx. Hence, it is all the more important to include the view of the maintenance teams from the outset.
Signposts for orientation
The SE documents form process artifacts or, in automotive terminology: outcomes. Even though there can be no standardized SE framework, many useful templates are available – no one has to start from scratch.
But a solid project setup is not everything, of course. Together with the system description as a model, engineering touchstones can be defined to structure the implementation. This involves a systematic review in order to be able to reflect on design decisions in good time. Here, another set of specific questions is recommended to check whether all relevant aspects have been covered thus far to ensure the effectiveness of the mission. The touchstones are also about transparency: Assumptions and criteria are made explicit to build a common understanding. Similar to an agile setting, SE relies intensively on communication and creates formats in which the participants share their experience and learn from each other.
Systems engineering thus offers orientation in two dimensions
- vertically by linking the product view with the process
- horizontally through the structuring of the system development process
AiD completes automotive systems engineering
The strengths of systems engineering lie in the coupling of the product view with the process. As concrete as the impetus for the product view is, the statements on the process model remain vague (apart from the identification of requirements). In the automotive industry in particular, the need for an integrated process model is obvious, in order to meet the many non-functional requirements in an efficient manner: regulatory requirements such as cybersecurity and functional safety or quasi-standards such as Automotive SPICE.
The lifecycle blueprint Automotive integrated Development (AiD)
This is where AiD comes into play: Automotive integrated Development, which we presented to you in the last issue of Kugler Maag Concepts. With this blueprint, we supplement SE with aspects relevant to vehicle development. With AiD as a process plug-in, we integrate the required activities across your product lifecycle whilst taking into account the perspectives of the parties involved. AiD also covers aspects which are not always addressed in traditional SE: the market phase so essential for the connected vehicle, when the fleet is exposed to cyber risks and digital services should ensure a constant cash flow for manufacturers.
//ASE Knowledge I
Model-based SE
Strong communication is vital in any project. And in the case of complex systems with many dependencies, it is crucial. Model-based systems engineering (MBSE) could offer a potential solution. This methodology focuses on modeling the target system to be developed in advance. The system model is then used as an alternative means of information exchange, rather than relying solely on documents.
A Model of the System supports Communication
According to the International Council on Systems Engineering, MBSE enables »the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.«1 Model-driven systems engineering (MDSE) goes one step further. In this methodology, the modeling goes beyond the technical description of a system and becomes an integral part of the development process. Figuratively speaking, the model automates communication.
Non-functional requirements are becoming increasingly prevalent, and the use of a system model as a means of information exchange provides an effective way to address these. One particularly interesting example are cybersecurity requirements, which are defined as non-functional in the architecture. In this case, the use of a system model ensures these requirements are always up-to-date and available throughout the life cycle of the vehicle series or platform.
//ASE Knowledge II
MOSA: Where Modularity meets Open-Source
Strong communication is vital in any project. And over the last 20 years, we’ve seen enormous growth in system integration. Various strategies are used to achieve this, including development using reference models, standardization and open-source software. One particularly interesting approach is the modular open system approach (MOSA). In the defense sector, systems are always integrated within wider digital ecosystems. But with this comes the risk that one of the companies involved could pull out at a later date. For long-term electronic systems, this is one of the most common reasons for components having to be replaced or changed – and with it comes the issue of vendor lock-in. To ensure that it was no longer reliant on its interface partners, the US Department of Defense used MOSA to define a set of technical and business framework conditions. MOSA is an architecture-based strategy for consolidating properties, such as the attractiveness of products, over a long life cycle.
Nothing gets swept under the carpet
The main aims of MOSA – and therefore the architectural requirements – are:
- to support technical modernization;
- to quickly reconfigure available components so they can respond to new threats;
- to ensure components can be reused and thus reduce their life cycle costs;
- to enhance interoperability, so that components can be replaced independently of one another.
According to Aviation Today, the central requirements of this modular approach are:
- partitioning,
- rigorous interface definitions,
- ease of replacement for relevant modules.
A rigorous modular interface specification covers physical, functional, and operational parameters and should be based on systems engineering principles. Open standards are used to implement interfaces because this produces the largest life cycle cost benefits.
Eatron takes a thorough approach – safe processes at a start-up for automotive software platforms
Eatron Technologies is a fast growing technology start-up that offers manufacturers a complete platform for software-defined vehicles. Based on this, Eatron has also developed applications for battery management and motion control. In order to convince in the safety-minded car industry, Eatron combines technological ambitions with safe and reliable development processes from the very beginning.
The car industry is moving towards the software-defined vehicle and new car architectures – the start-up Eatron has already been at the forefront with its software platform for five years. The Warwick-based technology company's connected automotive software platform combines edge, AI and cloud layers for series production. Other specific applications are built on this modular platform, BMSTAR for battery management or IMSTAR for motion control. In this context, robustness is an important feature to be capable of offering cross-manufacturer system solutions. Therefore, Eatron Technologies focuses on quality and safety from the very beginning. These are part of the start-up's DNA and are reflected in the development processes.
Machine Learning Engineering meets Automotive SPICE
Vehicle development is more and more influenced by autonomous driving which, in turn, requires more and more Machine Learning. But what exactly is Machine Learning Engineering and how does it impact the process landscape(s) of carmakers and their suppliers? The answer: Different and new approaches are necessary for a Machine Learning Engineering model evaluation.
In an interview, Bhaskar Vanamali and Christina Stathatou provide answers and present their approach on how to assess the Machine Learning capability and maturity.
The North American Perspective
As the snow becomes a distant memory and the annual flowers arise from the Earth, there are many things blooming within the North American Kugler Maag team as well.
We have begun a new series of webinars called Lunch & Learns where several of our Automotive SPICE Principal Assessors walk through a given part of the standard and provide a brief description of an Assessor's expectations and commonly-witnessed weaknesses for any given practice. These have drawn a large crowd of both OEMs and suppliers since understanding the typical pitfalls has been helpful.
Peter Abowd, our CEO, spoke at the Mathworks® Conference about Model-Based Design and how that can be used while achieving Automotive SPICE compliance. The talk delved into some of the challenges that teams face and how MBD can be employed effectively.
Over the past few months, we have been able to reinvigorate Gate4SPICE with one co-hosted session already completed in Q42021 with IBM (in Detroit, MI) around Capability Level 3 tips, and another gathering in Q2 with TeleNav (in Santa Clara, CA) for Machine Learning. We are co-organizing the next Gate4SPICE in July with BorgWarner and TeleNav for Combined Automotive SPICE and Functional Safety Assessments, which will once again be hosted in the great outdoors to hopefully enjoy sunshine and fresh air while discussing this important topic. We will also soon be announcing 1-2 more Gate4SPICE events in Q3-Q4. More soon!
On an even more entertaining front, we have started a podcast where Steve Tengler, Principal Consultant and Senior Contributor to Forbes, has begun recording some of his interviews to provide backstage access to the discussions with automotive executives.
And, yes, of course we are working with multiple companies to improve their services. Possibly due to step-function changes in the market or the increasingly demanded rigor from teams and suppliers, we’re already seeing companies planning budgets and assessments as far as Q1-2023. We consider this joyful engagements with all of you because we all want to see your continuous improvement.
Steve Tengler
KUGLER MAAG CIE North America
This is what China's car industry is engaged in right now
In the young but rapidly growing Chinese automotive industry, a wide variety of suppliers can be found. Different companies with different products face different challenges: All OEMs struggle with how to promote the ability to develop software and systems in-house, especially first- and second-generation manufacturers, including Geely and SAIC. Since in-house SW development is one of the advantages of the latest generation OEMs, namely NIO and Li-Auto, they in turn lack experience in system integration and validation.
Established system suppliers such as Bosch in China are repositioning their collaboration with OEMs and other suppliers. Fast delivery within the existing SW development and integration process is quite a problem. Bosch China has even accepted to be a tier 2 in an intelligent cockpit project, while the tier 1 is a small domestic company. There are more and more new vendors in the ADAS field, but whether they are capable of implementing a deployment project?
With the advent of the software-centric car, SW and HW are being decoupled, and tiers 3 to 4 of automated driving are being introduced in the real world – on a commercial basis. With this success, safety is one of the hottest topics in the Chinese automotive industry.
But OEMs as well as suppliers, market entrants and incumbents need to think about where and how to hire enough skilled engineers to bring their visions to Chinese roads.
Kailai Sun
KUGLER MAAG CIE China
Agile Automotive after the Hype
Agile practices had already made inroads into all areas of the car industry when we last conducted the Agile Automotive. State of Practice industry barometer in 2015. After a pioneering period – that saw the systematic roll-out of agile methods – followed a number of years of widespread deployment. As a result, we can now look back on a good dozen years of agile practice in the development of automotive electronics. So where are we now – half a decade after the heyday of agile introduction? Have the high expectations been met in industry?
It is worth highlighting those agile practices increasingly extend beyond software development and have now reached the realms of mechatronics development and portfolio management. Despite extensive experience in the field since over a decade, we also sense much uncertainty. Front-line practitioners now have a solid understanding of the role played by agile methods in complementing process maturity. But what about cybersecurity – will it even prevent the further use of agile practices? To provide pointers on this issue, our report offers a number of articles on this key question.
For the Automotive SPICE experts of tomorrow
Automotive SPICE® is increasingly emerging as the quasi standard in automotive development, far beyond software development. In recent years, proponents of ASPICE have extended the model to a host of different areas within mechatronic development, including cybersecurity and hardware and mechanical engineering. Moreover, we are seeing ASPICE extended to machine learning, agility and data management. As the scope of application for Automotive SPICE expands, so too does the need for a standardized basic understanding of the framework. To address this gap, four experts hailing from three different continents joined forces to compile a book packed full of tips for applying and understanding the Automotive SPICE process reference model. The result of this brainchild is called The Guide for Automotive SPICE Interpretation.
In this book, the authors explain everything even advanced users need to know, including information not included in the standard itself. Most usefully, the book interprets the 16 ASPICE processes that fall within the VDA scope (German Association of the Automotive Industry), so that users can implement these effectively and assessors can evaluate them correctly. The information presented is concise and to the point and, where relevant, the book directs readers to additional sources of information. Newcomers to Automotive SPICE might also like to explore the many free resources available on our extensive video channel.
Kugler Maag Cie joins the German chapter of INCOSE
To encourage the knowledge transfer among experts and to communicate the significance of an integrative approach in the development of mechatronic systems, Kugler Maag Cie is committed to the German systems engineering association.
With the German Systems Engineering association GfSE, we share the conviction that the product's future reliability, safety and functionality are already significantly determined in the design and development phase. GfSE is the German Chapter of INCOSE.
Open source: Is the automotive industry embracing the trend?
//Download the report for free
Automotive systems are increasingly making use of software-controlled services. New vehicle architectures aiming at software-defined vehicles are paving the way for greater integration. So does free/libre open source software (FLOSS) have a role in helping the automotive industry meet these ever more complex requirements? According to the industry barometer report Automotive FLOSS. State of Practice, all of the companies surveyed use at least one embedded system that employs FLOSS. However, the use of this software is (still) relatively limited. What remains to be seen is whether the introduction of new vehicle architectures will change this...
Externally, many companies in the automotive sector are lauding the benefits of open source and highlighting it as an attractive option – no doubt in part because they want to present themselves as an innovative employer to potential future employees. However, behind the scenes there is sometimes a sense of disillusion, with those in charge hesitant and unsure whether regulatory requirements around functional safety can be met. Kugler Maag Cie contacted a select group of experts from leading automotive manufacturers and suppliers and other embedded sectors, and asked them to what extent and for what purpose their company is using open source software for its vehicle development. The results are surprising – and also give reason for hope.
//Download the report for free