Consistent ECU versions and the Coupling Dilemma

For about a hundred years, a motor vehicle was an artifact of metal, rubber, oil, and gas—with zero lines of code. If there was math involved, it was done prior to production and for the first half of that century, this math was done with mechanical calculators. Motorists needing directions bought a map and in fixing things the torque wrench was considered a sophisticated tool.

Today the situation is very different. Software costs account for 10% of the vehicle bill of materials and are expected to reach 50% by 2030. A revolution in the automotive sector is happening within less than a decade. This series of articles probes into new mobility paradigms and looks at factors that will determine the future of the vehicle and the vehicle of the future. Last time we covered Improving Reductive Design with Intelligent Data Logging.

Today our topic is …

Coupling: Tight or Loose?

Loose Coupling

Let us simply start with BOINC. The Berkeley Open Infrastructure for Network Computing is a prime example of an extremely loose-coupled system. It consists, in essence, of servers and client software that communicate with each other to distribute and process work units and return the results. In practice, this means that participants install a special screensaver on their computers. This screensaver is the client that downloads a tiny fraction of an enormous scientific computation task, processes it when the CPU idles, and returns the result to the server. That way, a grid of volunteer machines forms a vast resource. It began with the search for extraterrestrial intelligence, but meanwhile, 32 science projects have made use of the capacity.

In a way, this network is even quite resilient, but at the cost of an abundance of resources. The downsides are obvious: The system is comparatively slow and has to be highly redundant and iterative. Tasks have to be segmented into subtasks that can be computed by an average PC unit. It is never known if a particular participant will process a certain task and the results have to be calculated multiple times. Only if a certain number of concurring results is returned, can validity be assumed. And even BOINC had to be designed with safety considerations, to obviate cheating and falsified results by users. 

Tight Coupling

Now, with this case of (extremely) loose coupling in mind, let us try a simple, working definition for coupling: Coupling is a degree of interdependence between modules, the measure of how much a change to one component affects other components in the system. 

A classic parameter for tight coupling is shared memory. In this sense, an example of tight coupling would be the mainframe computers from days of yore.

For the mainframe, the visuals of people in white lab coats, of slowly turning tape reels, of even punching holes into cards, are iconic. They evoke specialization, a centralized system, difficult to handle interfaces, huge ripple effects: If something went wrong, the entire organization had to wait until the problem was fixed. Veterans of those days fondly remember how well-hated IT departments were, being sort of impenetrable and everything depending on them. The IT department itself was a simile of tight coupling, for to bring in a new computer system meant a considerable investment of re-training and new experience gathering. 

Another, more recent, example of tight coupling is the ATM. It needs special hardware, firmware, and a banking application to work. These machines reliably do their job, fulfilling a narrow set of operations, but one component failing may mean no cash for the customer.

The other part of the equation, in both cases, is high performance (the mainframes, in particular, were often very fast for their time) and lower cost for the special use case the system was designed for. The ATM, mass-produced for its limited purpose, is cheap enough to be virtually ubiquitous. 

Coupling in Connected Vehicles

So, what architecture is to be preferred for the modern motor vehicle, incorporating more than 70 electronic control units (ECUs) and over 100 million lines of code in a plethora of functions—sensing, analyzing, transmitting? Not only will the software have to be maintained and updated, but additionally the data the sensors produce are an asset to be leveraged. Thinking of BOINC, we can safely assume that only a few people will wish to outsource the calculations for their park assist to a bunch of screen savers all over the world, as enthusiastic as the owners of those computers might be. As such, is tight coupling the answer: reduce the number of ECUs, introduce a concept of domain controllers, unify the operating system?

There are efforts in this vein underway, for this option seems desirable at first glance, however, as we just have seen, it is fraught with problems. Given the number and variety of the ECUs that are to be integrated, the effort may well be exponential. The disadvantages can be considerable: A system like this, tightly coupled, may show ripple effects of all sorts, some of them virtually unpredictable. The complexity of the integration task leads to a high probability of glitches in the implementation. The expenses for such a complex project, involving software and hardware, are as high as hard to calculate and success is not at all guaranteed. The system, in the end, may only be as strong as the weakest component and may not use the available resources very efficiently.

Another fact of the automotive industry is that ECUs, sensors, and other components are procured from a vast and international group of suppliers, which makes standardization of all the deep layers and technological details even more problematic—if doable at all. The purchase of electronics might become more difficult and costly, because the base of potential suppliers may shrink.

As such, the gain of tight coupling is questionable, in particular given modern requirements for data systems. This does not in itself mean that a low degree of coupling, even though it has been a doctrine of coding and software architecture for a long time, is the better solution. How will loose coupling have to look to fulfill all these tasks in the safe, flexible, scalable manner that is needed?

The Role of APIs

An example of loose coupling in everyday use (and less exotic than BOINC) are Application Programming Interfaces, APIs, which are a core connector of many web services today and offer a solution for countless request/response interactions. With an API, requests from clients are made to server URLs, using standard methods and parameters, and responses from the servers are returned in a standardized format as well. The fixed set of methods guarantees that the system behaves predictably. The clear structure allows us to abstract away everything that is happening beyond this interaction, with no need to consider the inner workings of the modules behind the interfaces. Components can be replaced and programs can serve multiple computing environments. 

If we take the API as an example of a contract between modules that are completely documented and defined, the next question is what such a concept means in the automotive sector. An important thing to consider is that we currently can not assume a motorized vehicle to be a cleanly decoupled system. Given that, it still has to be assured that, say, an update of the anti-lock braking (ABS) module does not have unintended repercussions on the power steering module. 

This means that the approach to updates, logging, and commands, has to be as precise, granular, and individual as possible. A rollout of a software update, for example, should update exactly the units and packages being targeted—none more, none less. The same goes for commands sent to particular vehicles or units as well as for the logging of data. Highly precise data logging may even open up access to data that was not readily available before.

The Sibros Solution

To reach these goals, Sibros provides full vehicle software updates with its OTA Deep Updater. Among the many parameters Deep Updater serves to ensure, is that the vehicle as a whole is at a consistent build level. This means that every ECU is at a software version that is compatible with all other ECUs.

The Sibros Deep Logger on the other hand supports a safe launch approach for software updates. Providing close monitoring of vehicles after an update, it verifies whether the software is delivering the intended result without unintended consequences. This remains an important aspect, even given best efforts to design a loosely coupled ECU architecture with well-defined interactions.

Sibros’ Deep Connected Platform (DCP) provides the following features:

• Embedded firmware - validated to run on all major TCU and gateway hardware supplier platforms and combinations
• Hardware agnostic - supports any hardware running a POSIX compliant OS
• Various operating systems - supports any POSIX compliant OS (for example, Mac, embedded Linux, QNX, AGL, Android)
• 95% product, 5% integration - product based deployment and configuration with low integration effort of both embedded firmware + SaaS applications
• Multi-cloud ready - runs on all major cloud providers
• GCP, AWS & Azure - horizontal scalability, portability, and abstraction  
• APIs and Web Portal - thoroughly documented and customized
• Safe and secure by design - compliance with functional safety and cyber security standards (UNECE WP.29, Uptane, ISO 26262, ISO 27001, ISO 9001:2015, Automotive SPICE, GDPR, and more)

With DCP data is updated, selected, stored, controlled, and transmitted with high precision and safety, little implementation effort, close control, and minimized driver interruption, giving reliability, flexibility and scalability the potential to reach new levels.

Coupling With Sibros

Drivers of today know their vehicle is increasingly defined by electronics. They expect differentiation between brands through innovation in this field. The automotive industry is transitioning from hardware to software and this change does not simply have to be managed, but proactively addressed.

Vehicle manufacturers have to optimize data access and versatility of functionality, without compromising on reliability and responsiveness. For vehicle owners, convenience is key. OEMs that are in the driver’s seat and exhaust the possibilities of new technologies without exhausting budgets or other resources, will come out ahead. 

To this end, Sibros’ hardware-agnostic approach and Deep Connected Platform deliver deep logging, fast transmission, high data compression, seamless updates, and remote commands, all via our web portal and well-documented APIs. Talk to us today.