How it started
Tracing the origins of software in automotive history, we arrive at the 1977 Oldsmobile Toronado, a pioneer that embarked on a journey that was to revolutionize vehicular technology in ways that were unforeseen at the time. This marked the dawn of an era, and within just four years, in the early 80s, General Motors was deploying an impressive 50,000 lines of engine control software throughout its fleet. This rapid advancement was a signpost of the acceleration that was to come, as other manufacturers swiftly caught onto the trend.
The pace of progress in the field of automotive software has been nothing short of meteoric. Today, modern vehicles rival the complexity of fighter jets, a statement that underscores not only the sophistication of their design but also their ubiquity. The comparison becomes even more startling when considering that a luxury car like the Mercedes S-Class houses more software lines than the gargantuan Airbus A380, a fact that never ceases to astound.
The catalyst behind this complexity is, paradoxically, the need for affordability. In the world of manufacturing, economics dictate that while aircraft are produced by the thousands for millions, automobiles are produced by the millions for thousands. This economic constraint shapes the development of car software, often with stringent budget limitations. The ramifications are profound; for instance, the choice of CPU in a car is subject to rigorous cost-cutting, which can have far-reaching consequences on software quality.
In response to these challenges, various initiatives have been launched. Standards and frameworks like HIS, AUTOSAR A-SPICE, and ISO26262 aim to streamline the development process, enhancing reliability and speed while managing costs. AUTOSAR, albeit dense with its documentation sprawling two meters in print form, has been instrumental in fostering collaboration between disparate automotive companies, albeit introducing its own set of complexities.
Yet, AUTOSAR’s reach has its bounds. It does not extend to the nascent stages of system development, where the conceptual groundwork of what constitutes the system is laid out. System Engineering fills this gap, operating as a precursor to software development, setting the stage for what features and functionalities will be incorporated into the final product. This is where the Car Configurator analogy comes to life; it’s an interactive tool that allows customers and engineers alike to understand the possible permutations and combinations of car features, which may or may not be mutually exclusive. In these digital playgrounds, we can endlessly tinker with configurations, creating dream vehicles that may stretch our budgets to the realm of fantasy. It’s an exercise that’s as enlightening as it is entertaining, offering a hands-on understanding of the intricate interplay of systems within a car. Such exercises are not merely for consumer engagement but serve as educational tools for those who build these complex machines.
In essence, the use of software in cars has transcended beyond mere function; it has become a bridge connecting engineering prowess to consumer experience, a canvas where imagination meets metal, rubber, and silicon. As we continue to navigate this landscape, it’s evident that software is not just a component of the automotive system; it’s the very heart of modern vehicle design and functionality. Delving deeper into the world of automotive innovation, let’s consider the example of “Keyless Entry” — a term that seems to contradict itself. The key, while not inserted into a lock, remains a critical piece of the puzzle. The Electronic Control Unit (ECU) in the car communicates with this key, using a variety of sensors and antennas to detect its presence. My personal involvement in developing the Keyless system for my car revealed the intricate dance of hardware and software. From proximity sensing, signal encryption, to the fail-safes like Near Field Communication (NFC) for those times when the car battery waves the white flag, the system is a technological marvel crafted by the unsung heroes of engineering. System Engineering is where all these disparate elements coalesce. It starts with a meticulous gathering of requirements, setting the stage for what will become a symphony of interconnected parts. IBM Rhapsody, armed with the HarmonyMBE profile, is akin to the maestro’s baton in this orchestra. It allows engineers to craft a model that not only outlines the system’s architecture but imbues it with life, anticipating and accommodating the myriad functions it will perform.
HarmonyMBE, conjured from the mind of Andy Lapping, is not just a set of tools; it’s a methodology that empowers engineers to dissect and understand their design challenges thoroughly. It provides a structure to the often-chaotic creativity of engineering, guiding the analysis of requirements with a suite of helpers that ensure every aspect of the system is accounted for and no stone is left unturned.
Moving forward, Model Transformation is the process that transmutes these meticulously crafted models into practical applications. Using the Model to Model (M2M) engine, Rhapsody facilitates the flow of information, ensuring that the transition from one model to another is seamless and coherent. This step is not just a mere conversion but a translation of conceptual models into actionable blueprints for software development and integration.
Within this ecosystem, AUTOSAR emerges as a pivotal domain. It’s where the rubber meets the road in terms of standardization and interoperability. With M2M, we can take the abstract concepts laid out in Systems and Architectural models and crystallize them into AUTOSAR models, whether Classic or Adaptive. These models are not static; they are living documents that can be manipulated and refined using Rhapsody’s interface, which is as versatile as it is robust, allowing for a degree of manipulation akin to that of UML or SysML.
The journey from a Systems Model and an Architecture Model to AUTOSAR models is intricate. It’s a path that leads us to the creation of UML models to implement AUTOSAR Software Components (SWC’s). Rhapsody’s UML is not just a notation; it’s a language that speaks directly to the software, instructing it on how to behave and interact within the car’s ecosystem. The Helpers in the ARXF profile are the translators, turning the UML directives into code that the car’s systems can understand and execute.
This code is robust; it’s designed to be implemented in a Real-Time Environment (RTE) without modification. But should the need arise, the Target debugger is the diagnostic tool that engineers turn to. It’s the detective in the plot, uncovering clues and pinpointing issues within the SWC’s.
In essence, what I present here and discuss in my presentations is just the tip of the iceberg. The full scope of “Next Level Automotive Development” using Rhapsody is vast. It’s a realm where innovation is not just imagined but executed, where ideas become tangible realities that can be touched, felt, and experienced. For those eager to see this world, to witness the transformative power of Rhapsody and the HarmonyMBE profile in action, I extend an invitation.
Reach out to me (wvdheiden@sodiuswillert.com) , and I will arrange a demonstration that will not just inform but inspire you.
It’s a glimpse into the future of automotive development, a future where the vehicles we drive are as intelligent as they are intuitive, as connected as they are capable, and as reliable as they are revolutionary.
Looking forward to hearing from you,
Walter van der Heiden – SodiusWillert
wvdheiden@sodiuswillert.com
