Handboek · hoofdstuk 45Systems engineering en het V-model

Een gebruiker wil een bewoonbaar station met bruikbare plantproductie en weinig operatorwerk. Dat is nog geen eis voor één computer. Kies de systeemgrens: het stationsbrein omvat centrale planning en logging, gekoppeld aan lokale regelaars. De 12 V-module en het 48 V-stationsnet houden eigen actuatoren en energiebalansen.

Leg stakeholders, gebruiksomstandigheden en succescriteria vast. Een operator wil herstelbare storingen; een onderhoudsmedewerker wil versieherkomst; een gebruiker wil het bedoelde comfort. Een architectuur is een antwoord op die behoeften. Begin daarom niet met ‘koop een Pi’ als onbesproken oplossing. Maak aannamen zichtbaar en onderzoek wat bij een grenswijziging mee moet veranderen.

Een goede eis noemt onderwerp, meetbare prestatie, omstandigheden en acceptatiegrens. ‘Snel en betrouwbaar’ is niet toetsbaar. ‘De centrale logger markeert een telemetriemeting ouder dan 90 s als verouderd, gemeten aan het opgegeven meettijdstip’ heeft wel een concrete betekenis. Leeftijd en klokfout moeten daarbij afzonderlijk worden beheerd.

Houd iedere eis atomair genoeg om één status te kunnen geven. Vermijd een zin die zowel klimaatkwaliteit, energiebesparing als onderhoud regelt. Geef een uniek ID, bron, rationale, eigenaar en toetsmethode. Een gekozen grens is eerst een ontwerp- of proefcriterium; een groen vinkje vraagt daadwerkelijk bewijs op de bedoelde versie.

Een functionele eis vraagt wat gebeurt: plannen, loggen, alarmeren of een voorstel weigeren. Een niet-functionele eis beschrijft kwaliteit of beperking: tijd, nauwkeurigheid, beschikbaarheid, onderhoud, energie of beveiliging. Beide sturen architectuur. Een logfunctie met onbeperkte blokkerende schrijftijd kan een regelfunctie onbruikbaar maken.

Beschrijf eisen in waarneembare termen. Een percentile-eis voor rekentijd vraagt hardware, bestandsgrootte, belasting, meetduur en uitgesloten onderhoudsfasen. Een deterministische deadline vraagt een andere analyse dan een gemiddeld snelle uitvoering. Beveiligings- en privacyvoorwaarden kunnen harde selectiepoorten zijn.

Van iedere behoefte ga je naar systeem- en deeleisen, ontwerpbesluiten en bewijsstukken. Omgekeerd moet een implementatiedetail terug te voeren zijn op een behoefte of gemotiveerde technische keuze. Zo herken je een ontbrekende toets én een onnodige functie.

Een teststatus hoort bij versie, configuratie, testmethode en resultaat. ‘Getest’ zonder identiteit kan een oude interface betreffen. Eén eis kan analyse, inspectie en proef tegelijk nodig hebben. Een unit-test voor een berichtvalidator bewijst geen netwerkbeschikbaarheid of thermische prestatie van het volledige station.

De centrale Pi plant en logt; lokale controllers voeren hun eigen snelle regel- en beveiligingsfuncties uit. Energievoorstellen gaan door een expliciete supervisorinterface. De bestaande Mega van de module, luchtknoop en energiecontrollers behouden hun bussen, adressen en pin-eigenaars.

Kies functies, datastromen, grenzen en foutverantwoordelijkheid vóór de fysische bekabeling. Een gedeelde logger mag geen deadline van de lokale regeling opeisen. De twee energienetten wisselen informatie en eventueel expliciet beschreven energie uit; hun verbruiken en bronnen worden niet dubbel geteld. Koppel een storing aan de functie die haar detecteert, begrenst en aan de operator verklaart.

Een interfacecontract bevat fysische signalen, elektrische niveaus en eenheden, maar ook timing, eigenaarschap, foutstatus en versies. Een MQTT-bericht met temperatuur moet vertellen welke toestand en meetplaats bedoeld zijn. Een leeg meetveld is geen nul graden.

Definieer commando-ID, bron, boot-ID, meettijd, vervaltijd, modus en bevestiging. Een ontvangen bevestiging kan ontvangst of uitvoering betekenen; leg het verschil vast. Bij herstart moet replaybeleid niet vergeten worden: de kleine lesvalidator bewaart alleen een set in RAM en toont dus nog geen volledige herstartbeveiliging. Een productiecontract vraagt boot/sequence, duurzame toestand of een aantoonbaar nieuwe sessie.

Links specificeer en ontwerp je van gebruikersdoel naar systeem, interfaces en componenten. Onderin realiseer je de onderdelen. Rechts toets je componenten, integreer je interfaces, verifieer je systeemeisen en valideer je het beoogde gebruik. De lijnen over de V verbinden de bronvraag met passend bewijs.

Een testontwerp begint bij het schrijven van de eis. Daardoor kunnen proefopstelling, meetbereik en instrumenten tijdig worden voorzien. Iteratie blijft mogelijk: een integratiefout kan de interface terug naar review sturen. Het model ordent bewijsniveaus en is geen verplicht lineair tijdschema.

Vergelijk haalbare alternatieven op dezelfde functie en systeemgrens. Harde voorwaarden zoals lokale actuatorbeheersing worden eerst gecontroleerd. Een alternatief dat daar niet aan voldoet wordt geen winnaar door een goedkope prijs.

Gebruik daarna criteria met een gedocumenteerde schaal en gewichten. Scores zijn beoordelingen, geen nauwkeurige fysische kansen. Vermijd dubbeltellen van hetzelfde voordeel onder meerdere namen. Noteer bronnen, onzekerheid en gevoeligheid. Een robuuste keuze verandert niet bij iedere kleine aannamenwijziging.

Een systeemversie omvat software, firmware, schema, pin/adreslijst, kalibratie, modelparameters, datasets en eisen. Een Git-commit alleen is onvoldoende als de dataset of ingestelde sensorcorrectie buiten het repository verandert. Bewaar een manifest met identifiers, hashes, toolversies en verantwoordelijke.

Een baseline bevriest een samenhangende referentie. Een wijzigingsverzoek beschrijft trigger, betrokken eisen/interfaces, risico, toetsimpact en terugrol. Maak de testomgeving reproduceerbaar en vergelijk werkelijk gebruikte configuratie met het manifest. Een hash toont identiteit; hij zegt niet dat een bestand goed of bevoegd is.