"Naarmate we overgaan van een wereld van ingebedde systemen naar een wereld van cyberfysieke systemen en systemen-van-systemen, is software niet langer slechts een afscheidbaar onderdeel van een systeem."
Parallelle functionele architecturen worden dan geïntegreerd in een logische architectuur die gerelateerde functionele architectuurelementen samenvoegt tot gerelateerde logische eenheden die de conceptuele architectuur van het beoogde product weerspiegelen. De logische architectuur moet echter implementatie-onafhankelijk blijven. De fysieke architectuur omvat de technologiedomeinen die zullen bijdragen tot de realisatie van het eindproduct, bv. mechanica, hardware, vloeistofdynamica, enz. Als zodanig verschilt RFLP niet wezenlijk van andere system engineering paradigma's, zoals CAFCR.
Het probleem met de implementatie van RFLP door de klant was dat de P-fase zich alleen richtte op mechanische en hardwarespecificaties en architectuur. De softwarearchitectuur werd niet aangepakt op het niveau van de systeemengineering. Het resultaat was een systeem dat werd gedecomponeerd tot ECU/CPU en actuatorniveau voordat de softwarearchitectuur aan bod kwam. Bijgevolg waren er in een voertuig met 100 ECU's effectief 100 softwarearchitecturen.
Het is duidelijk dat 100 ECU's niet volledig onafhankelijk zullen werken - ze zullen met elkaar moeten communiceren. En die communicatie werd inderdaad vergemakkelijkt door de hardware- en signaalontplooiingsarchitectuur. De relatie tussen onderling afhankelijke ECU's was echter los en informeel, d.w.z. er was weinig softwaresysteemarchitectuur. Het was bijvoorbeeld bekend dat er binnen de software-"architectuur" van een bepaalde reeks voertuigen acht verschillende bronnen voor snelheidsmeting waren.
Software behandelen als een deelbaar voertuigonderdeel heeft de afgelopen twintig jaar gewerkt, waardoor OEM's in de auto-industrie ingewikkelde voertuigen konden blijven ontwerpen en bouwen door gebruik te maken van hun toeleveringsketen. Tier 1-leveranciers konden hun eigen doelen nastreven, losjes gekoppeld met andere leveranciers, waarbij de OEM alleen de bijbehorende producten integreerde en testte. In vorige generaties auto's werd minder dan 10% van de software in de auto geproduceerd door de OEM waarvoor ik werkte.
Met de komst van voertuigen als cyberfysische systemen is deze benadering niet langer toereikend - een feit dat door 'mijn' OEM wordt erkend. Cyberfysische voertuigen zijn niet langer ingewikkeld; ze zijn complex, met alles wat dat met zich meebrengt. Deze complexiteit vraagt om een andere benadering van softwarearchitectuur om redenen die worden benadrukt door een eenvoudige analogie: Als je op blote voeten rondloopt en op een scherp voorwerp gaat staan, bijvoorbeeld een glasscherf, zal je autonome zenuwstelsel onmiddellijk actie ondernemen om het gewicht van je voet te halen. Maar om het glas van je voet te verwijderen, is een systeemreactie nodig die wordt geleid door je centrale zenuwstelsel. In een volgende generatie, mogelijk autonoom voertuig, zal een lekke band tijdens het rijden een vergelijkbare reactie vereisen - lokale beperking gevolgd door systeembrede aanpassing. Dit kan niet worden bereikt door software te behandelen als een losse verzameling van deelbare componenten.
Om alle soorten cyberfysische voertuigen en systemen te realiseren, moet software worden behandeld als een gelijkwaardige speler in de systeemengineering. In RFLP-termen moet de P-fase niet alleen tastbare fysieke domeinen zoals hardware en mechanische engineering omvatten, maar ook ontastbare software engineering. Het moet mogelijk zijn om een logische architectuur te ontleden in onderling afhankelijke fysieke architecturen door voort te bouwen op de sterktes en zwaktes van elk bijdragend domein en deze gelijkwaardig uit te ruilen.
Nu we overgaan van een wereld van ingebedde systemen naar een wereld van cyberfysieke systemen en systemen-van-systemen, is software niet langer slechts een te scheiden systeemcomponent. Software moet worden behandeld als een gelijkwaardige speler in en bijdrager aan Systems Engineering.
Meer lezen
Een uitbraak van overmoed
Software is het medium van de digitalisering. Als je software niet begrijpt, heb je geen hoop om met een fatsoenlijke digitaliseringsstrategie te komen.
Software is geen onderdeel van een voertuig
OEM's in de auto-industrie hebben zich ontwikkeld tot zeer efficiënte organisaties voor uitbesteding en systeemintegratie. Alles wat te maken heeft met een voertuig wordt gezien als een component, inclusief software. Het hele automotive system engineering proces behandelt software als een onderdeel van een voertuig. Hierdoor denken ze niet na over de software als een heel systeem.
Abstractie versus vaagheid in software-engineering
Sommige software engineering teams hebben moeite met het begrijpen van het verschil tussen abstractie en vaagheid. Aangezien het ene essentieel is voor de architectuur en het ontwerp van complexe systemen en het andere leidt tot technische schuld en slechte softwarekwaliteit, moeten softwareteams het verschil begrijpen.