Philip Koopman’s Post

The question is: what are the driving factors behind making such architectural decisions? I think Conway's law has a strong role, but there might be more. In my view the most important factor driving architectural decisions is Hardware BoM optimization. Just looking at the hardware BoM means to only look at production costs, Total Cost of Ownership is being neglected. We end up in tailormade systems, with enormous effort for optimizing and integrating software again and again - for something that has already been working successfully in a different system. The automotive industry does not have a strong tradition in decoupling systems into modular components with stable interfaces. Well-managed APIs would allow separate development, testing and integration of components - actually for both hardware and software. This is a competence the industry should try to apply systematically in the architecture development.

I fully agree that high-cohesion and low-coupling are important properties of well designed architectures, and that the way of achieving them has to change when moving to more centralized E/E architectures. Anyhow, both are some of the key principles of good software modularization. But just ensuring high-cohesion and low-coupling somehow will not ensure a working SDV. The both principles need to be well applied to design a layered architecture with well managed interfaces, ensuring decoupling from the vehicles hardware capabilities and software based features. The lower layers need to describe the physical capabilities and further properties of the vehicle, such that the higher layer functional application software can use these capabilities & data to establish software defined vehicle features. This imho also requires that the application software is able to adapt to the given vehicle capabilities and states. The functional application software also needs multiple layers with well managed interfaces (low coupling), to decouple for instance essential safety critical vehicle dynamics features, and further planning or strategic features on top of them. What do you think?

I would probably push the end of low coupling era of isolated modules waaaay back to the end of '90s. That's the time where systems got gradually more and more interconnected via CAN. It was used to publish data from ECU-attached sensors and other ECUs became reliant on this data. This is where tight coupling was born. Go and screw with ABS sensor on some 2005 high-end car and take it for a ride. You'll find errors in ECUs all over the car, usually the problem cascading and becoming worse and worse ending up with Christmas tree-like instrument cluster. This is not a new problem. This problem exists for more than a decade. Just, up until now, the overall complexity of the in-vehicle systems was so low the car would eventually be able to be driven without major software-induced breakdowns. Mostly. I would not hail the old days. Coupling is not a new problem introduced by SDV attempts. This is a persistent problem which only got exposed by increased complexity as people of automotive are mostly not capable of doing other than tightly-coupled architectures.

Thank you, Philip Koopman for sharing this insightful topic. I'm particularly intrigued by the segment on Conway's Law. It makes me wonder how this principle relates to the aggregation of power within organizations. People often attempt to centralize specific responsibilities that align with their own incentives. In my experience, module owners frequently negotiate and select functions within their zone controllers based on their interests, sometimes prioritizing these over broader architectural considerations. Sometimes they push for certain "important" functions, other times they push off certain low value or technically challenging functions. Thoughts?

One might well wonder why people with decades of experience in making numerous embedded systems work reasonably well together without critical dependencies suddenly came to believe that they could throw all of their vehicular tasks and problems into one giant stew and expect anything good to come out of that. More than profits, anyway.

Having just returned from the UK's Automotive Electronics AESIN Conference.. and from my own experience of working with OEMs and Tier 1s... I think there are other influences to the coupling/cohesion problem: Part 1: i) The seniors in OEMs still have a mechanical perspective and still believe they are 'bolting on' stuff and don't recognise the complexity inherent from the interfaces (the impact is more limited in mechanics). ii) The OEMs buy from a Tier 1 supply chain, which means they have little sway over the system architecture, but assemble a jigsaw of 'badly fitting' parts (where the complexity of interfaces are disguised in CAN signals) iii) There is far too much hype about the 'electronic' architecture e.g. 'zonal architecture' masquerading as 'software architecture'... when at a system level, the initial concepts should be platform independent (but see constraint ii)) and be allocated according to platform needs (including sensor bandwidth, latency etc) ...

A most informative read. Appreciated the analogies! Reminds me of a yarn told to me a while back. SCATS (Sydney Coordinated Adaptive Traffic System) was earlier developed on a PDP-11. Scarce bits and bytes led to lean design and comms. You could say it is low coupling/high cohesion. When ported to PC the original code was largely retained. I saw fixed point division. Spaghetti but lean code inside, but harmonious integrated set of software and hardware using simple comms with collaborative multi-module SW/HW stack. In the 90s the software shown in Hong Kong running over a humble modem? connection running live from Sydney operation with incredible snappy user interface in HK. (NB Above story is historical and not referring to current situation.)

Agree ok the Conway Law part…this definitely is the latest roadblock to (any) transformation / disruption. Coupling / cohesion themselves however aren‘t ‚rocket science‘ to master..just need to understand, describe (and laser-focus) on the customer needs / features / control points. Spend sufficient time during definition phase to picture the target state. Set up / leverage existing APIs across the stack (and stick to them!!!). Separate concerns though system design along these APIs. The ‚component level‘ then is only a form factor, adjustable and replaceable in line with scaling needs. This job however cannot be dont by those who ‚always did it this way‘, in an organization that mostly serves those already in charge and protecting their stakes…

The reference to Conway's Law (which I had never heard of before) has made me think. Two thoughts occupy my mind at the moment: 1) That high-capacity buses are to blame may be an example of a "perverse incentive": https://en.wikipedia.org/wiki/Perverse_incentive 2) The semantics of the word "infotainment" may reveal the SDV problem in a nutshell: If profit is the development driver, and if profit from entertaining the occupants gets the same development emphasis as the (much more opaque) profit of keeping people safe, you may end up where VW and Volvo have apparently positioned themselves. My thoughts digressed to this article: https://en.wikipedia.org/wiki/Good_regulator and ended in a place where they have been before: SDV systems which can act on behalf of the driver must feature dynamic objects which in a flexible way evolve with time: 1) Is there any risk of collision? 2) Is it at all collideable? 3) Is it mentioned in any law or guideline? 4) What can I expect from its behavior? 5) Can I delete the object because I, for instance, have passed it? I expect that an object model may be too rigidly defined: The answer to the question "fog or elephant?" may simply arrive too late for a proper response to be feasibile.