{"id":3738,"date":"2026-10-20T08:00:00","date_gmt":"2026-10-20T06:00:00","guid":{"rendered":"https:\/\/datastorms.eu\/?p=3738"},"modified":"2026-10-01T11:45:03","modified_gmt":"2026-10-01T09:45:03","slug":"wat-is-een-system-of-systems","status":"publish","type":"post","link":"https:\/\/datastorms.eu\/nl\/2026\/10\/20\/wat-is-een-system-of-systems\/","title":{"rendered":"Wat is een system of systems?"},"content":{"rendered":"<p>Een <strong>system of systems<\/strong> is een verzameling van onafhankelijke systemen die samenwerken om een gezamenlijk doel te bereiken dat geen van die systemen afzonderlijk kan realiseren. Elk deelsysteem heeft zijn eigen beheer, zijn eigen levenscyclus en kan ook zelfstandig functioneren. Denk aan een haven waar radarsystemen, communicatieplatformen, scheepsbesturing en logistieke software samen \u00e9\u00e9n ge\u00efntegreerd geheel vormen. In dit artikel beantwoorden we de meest gestelde vragen over systems of systems en de rol van systems engineering daarbinnen.<\/p>\n<h2>Waaruit bestaat een system of systems precies?<\/h2>\n<p>Een system of systems bestaat uit meerdere zelfstandige systemen die elk een eigen functie vervullen, maar samen een overkoepelend vermogen leveren. De deelsystemen zijn operationeel en beheersmatig onafhankelijk, maar zijn onderling verbonden via interfaces, protocollen of datastromen om gezamenlijk een complexer doel te dienen.<\/p>\n<p>Concreet herken je een system of systems aan de volgende kenmerken:<\/p>\n<ul>\n<li><strong>Operationele onafhankelijkheid:<\/strong> elk deelsysteem kan zelfstandig blijven functioneren, ook als de verbinding met andere systemen wegvalt.<\/li>\n<li><strong>Beheersmatige onafhankelijkheid:<\/strong> elk systeem heeft een eigen eigenaar, budget en ontwikkeltraject.<\/li>\n<li><strong>Emergent gedrag:<\/strong> het samenwerkingsverband levert mogelijkheden op die los van de individuele systemen niet bestaan.<\/li>\n<li><strong>Geografische spreiding:<\/strong> de deelsystemen bevinden zich vaak op verschillende locaties of worden door verschillende organisaties beheerd.<\/li>\n<li><strong>Evolutie:<\/strong> de samenstelling verandert in de tijd: systemen worden toegevoegd, vervangen of aangepast.<\/li>\n<\/ul>\n<p>Een praktisch voorbeeld uit de civiele techniek: een slimme waterkering combineert sensornetwerken, een SCADA-systeem, een beslissingsondersteunend platform en communicatie-infrastructuur. Geen van die componenten is op zichzelf de waterkering. Samen vormen ze het systeem dat de veiligheid borgt.<\/p>\n<h2>Wat is het verschil tussen een system of systems en een gewoon systeem?<\/h2>\n<p>Het kernverschil is onafhankelijkheid. Bij een gewoon systeem zijn alle componenten ontworpen en beheerd als \u00e9\u00e9n geheel, met \u00e9\u00e9n eigenaar en \u00e9\u00e9n doel. Bij een system of systems zijn de deelsystemen zelfstandige entiteiten met eigen doelen, eigenaren en levenscycli die tijdelijk of permanent samenwerken.<\/p>\n<p>Dit verschil heeft grote gevolgen voor hoe je zo&#8217;n systeem ontwerpt en beheert:<\/p>\n<ul>\n<li>Een gewoon systeem heeft een centrale architect die alle ontwerpbeslissingen neemt. Bij een system of systems zijn meerdere organisaties betrokken, elk met eigen belangen en prioriteiten.<\/li>\n<li>Bij een gewoon systeem zijn interfaces intern en volledig controleerbaar. Bij een system of systems zijn interfaces extern, gestandaardiseerd en soms niet aanpasbaar.<\/li>\n<li>De eisen van een gewoon systeem zijn stabiel en hi\u00ebrarchisch gedecomponeerd. Bij een system of systems zijn eisen diffuus en moeten ze worden onderhandeld tussen partijen.<\/li>\n<\/ul>\n<p>Kortom: een gewoon systeem ontwerp je van boven naar beneden. Een system of systems vraagt om orkestratie tussen partijen die niet altijd dezelfde agenda hebben.<\/p>\n<h2>Welke soorten systems of systems bestaan er?<\/h2>\n<p>Er bestaan vier erkende typen systems of systems, ingedeeld op basis van de mate van centrale sturing en de vrijwilligheid van deelname door de afzonderlijke systemen.<\/p>\n<ul>\n<li><strong>Virtual:<\/strong> er is geen centrale sturing en geen formeel afgesproken doel. De samenwerking ontstaat spontaan, vaak onbewust. Het internet is het bekendste voorbeeld.<\/li>\n<li><strong>Collaborative:<\/strong> de deelsystemen kiezen er vrijwillig voor om samen te werken om een gedeeld doel te bereiken, maar er is geen centrale autoriteit die hen dwingt. Internationale noodhulpco\u00f6rdinatie werkt vaak op deze manier.<\/li>\n<li><strong>Acknowledged:<\/strong> er is een erkend overkoepelend doel en een centrale systeemintegrator, maar de deelsystemen behouden hun eigen eigendom en beheer. Dit type komt veel voor in infrastructuurprogramma&#8217;s.<\/li>\n<li><strong>Directed:<\/strong> er is een centrale autoriteit die het geheel aanstuurt en de deelsystemen zijn specifiek gecre\u00eberd of aangewezen voor dit doel. Militaire commandosystemen vallen hier vaak onder.<\/li>\n<\/ul>\n<p>Voor systems engineers in de Nederlandse infra- en maritieme sector is het <em>acknowledged<\/em> type het meest herkenbaar: meerdere aannemers, opdrachtgevers en leveranciers werken samen binnen een programma, elk met eigen systemen en verantwoordelijkheden.<\/p>\n<h2>Waarom is een system of systems moeilijker te managen dan een enkel systeem?<\/h2>\n<p>Een system of systems is moeilijker te managen omdat complexiteit zich op meerdere lagen tegelijk manifesteert: technisch, organisatorisch en bestuurlijk. Er is geen enkel aanspreekpunt dat alle beslissingen kan nemen, en veranderingen in \u00e9\u00e9n deelsysteem hebben onvoorziene gevolgen voor de rest.<\/p>\n<p>De grootste uitdagingen zijn:<\/p>\n<ul>\n<li><strong>Emergent gedrag:<\/strong> het geheel gedraagt zich anders dan de som der delen, en dat gedrag is vooraf moeilijk te voorspellen of te testen.<\/li>\n<li><strong>Interfacebeheersing:<\/strong> elke koppeling tussen systemen is een potentieel risico. Als \u00e9\u00e9n systeem zijn interface wijzigt, kan dat een kettingreactie veroorzaken.<\/li>\n<li><strong>Verdeeld eigenaarschap:<\/strong> niemand heeft volledig zicht op het geheel, terwijl iedereen verantwoordelijk is voor een deel.<\/li>\n<li><strong>Traceability:<\/strong> eisen op system-of-systems-niveau zijn moeilijk te herleiden naar verificatie op deelsysteemniveau, zeker als die systemen door verschillende partijen worden gebouwd.<\/li>\n<li><strong>Evolutie en versiebeheer:<\/strong> deelsystemen worden onafhankelijk van elkaar bijgewerkt, waardoor compatibiliteitsproblemen op de loer liggen.<\/li>\n<\/ul>\n<p>Voor de systems engineer betekent dit dat traditionele methoden zoals een hi\u00ebrarchische eisenstructuur in een Excel-bestand onvoldoende zijn. De samenhang tussen systemen vraagt om een aanpak die relaties, afhankelijkheden en veranderingen centraal bijhoudt.<\/p>\n<h2>Hoe pas je systems engineering toe op een system of systems?<\/h2>\n<p>Systems engineering toepassen op een system of systems begint met het defini\u00ebren van de overkoepelende capability die het geheel moet leveren, en vervolgens het in kaart brengen van de bijdragen van elk deelsysteem daaraan. De aanpak verschilt wezenlijk van klassieke systems engineering voor enkelvoudige systemen.<\/p>\n<p>Een effectieve aanpak omvat de volgende stappen:<\/p>\n<ol>\n<li><strong>Definieer de mission-level-eisen:<\/strong> wat moet het system of systems als geheel kunnen? Formuleer dit onafhankelijk van de technische invulling van de deelsystemen.<\/li>\n<li><strong>Breng de deelsystemen en hun rollen in kaart:<\/strong> welke systemen dragen bij, wat is hun functie, en wie is de eigenaar?<\/li>\n<li><strong>Stel interface control documents (ICD&#8217;s) op:<\/strong> leg vast hoe systemen met elkaar communiceren en welke afspraken gelden voor wijzigingen.<\/li>\n<li><strong>Definieer verificatie op system-of-systems-niveau:<\/strong> hoe toon je aan dat het geheel de mission-level-eisen haalt, ook als deelverificaties al zijn afgerond?<\/li>\n<li><strong>Beheer afhankelijkheden actief:<\/strong> houd bij welke eisen, functies en verificaties met elkaar verbonden zijn, zodat een wijziging in \u00e9\u00e9n systeem direct zichtbaar maakt wat elders moet worden aangepast.<\/li>\n<\/ol>\n<p>Model-based systems engineering (MBSE) leent zich goed voor deze aanpak, omdat het relaties en traceability centraal stelt in plaats van documenten. Daarmee wordt de samenhang tussen systemen beheersbaar, ook als die systemen door verschillende organisaties worden ontwikkeld.<\/p>\n<h2>Welke tools ondersteunen systems engineering voor een system of systems?<\/h2>\n<p>Tools die systems engineering voor een system of systems ondersteunen, moeten in staat zijn om eisen, functies, interfaces en verificaties over meerdere systemen heen te beheren en te verbinden. Losse documenten en spreadsheets schieten hier tekort omdat ze geen relaties vastleggen en traceability niet afdwingen.<\/p>\n<p>Gangbare toolcategorie\u00ebn zijn:<\/p>\n<ul>\n<li><strong>MBSE-platforms:<\/strong> tools zoals Cameo of Rhapsody bieden modelleerondersteuning op basis van SysML, maar vragen een aanzienlijke investering in licenties en opleiding.<\/li>\n<li><strong>Requirements management tools:<\/strong> platforms zoals DOORS of Jama Connect richten zich op eisen en traceability, maar missen vaak de bredere systems-engineeringcontext.<\/li>\n<li><strong>Integrale dataplatformen:<\/strong> flexibele platforms die eisen, objecten, relaties en verificatie in \u00e9\u00e9n centrale omgeving combineren, en die aansluiten op bestaande werkwijzen en systemen via API-koppelingen.<\/li>\n<\/ul>\n<h2>Hoe Datastorms helpt bij systems engineering voor een system of systems<\/h2>\n<p>Wij begrijpen dat een system of systems de grenzen van traditionele tooling overschrijdt. Datastorms is het no-code-informatieplatform waarmee systems engineers grip krijgen op de volledige complexiteit van hun projecten, ook wanneer meerdere systemen, eigenaren en organisaties betrokken zijn. Concreet biedt ons platform:<\/p>\n<ul>\n<li>Een centrale omgeving voor eisendecompositie, traceability en verificatiematrices over meerdere systemen heen.<\/li>\n<li>Een semantische datastructuur die zich aanpast aan evoluerende systeemlandschappen, zonder dat je de hele omgeving opnieuw hoeft in te richten.<\/li>\n<li>Koppeling via API met tools die al in gebruik zijn, zodat je bestaande werkwijzen niet overboord gooit.<\/li>\n<li>Een centrale bibliotheek van objecten, definities en templates voor standaardisatie en snellere kennisoverdracht.<\/li>\n<li>ISO 27001-certificering en 100% Europese hosting, zodat gevoelige projectdata onder eigen regie blijft.<\/li>\n<\/ul>\n<p>Wil je zien hoe dit werkt in de context van jouw projecten? <a href=\"https:\/\/datastorms.eu\/nl\/proeflicentie\/\">Probeer Datastorms gratis<\/a> en ontdek hoe je systems engineering voor een system of systems eindelijk beheersbaar maakt.<\/p>\n<div class=\"wp-block-seoaic-faq-block\">\n    <h2 class=\"seoaic-faq-section-title\">Veelgestelde vragen<\/h2>\n            <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Hoe begin ik met het defini\u00ebren van eisen voor een system of systems als de deelsystemen al bestaan?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Begin niet bij de techniek, maar bij de overkoepelende capability die het geheel moet leveren. Stel jezelf de vraag: wat moet dit system of systems kunnen dat de afzonderlijke systemen niet kunnen? Vertaal dat naar mission-level-eisen en werk daarna terug naar de bijdrage van elk bestaand deelsysteem. Zo voorkom je dat bestaande technische beperkingen de ambitie van het geheel bepalen.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Wat is het grootste praktische fout die teams maken bij het integreren van meerdere onafhankelijke systemen?            <\/h3>\n            <p class=\"seoaic-answer\">\n                De meest voorkomende fout is het onderschatten van interfacebeheer. Teams richten zich op de functionaliteit van de afzonderlijke systemen, maar vergeten heldere afspraken te maken over hoe systemen met elkaar communiceren en wie verantwoordelijk is bij een interfacewijziging. Stel daarom zo vroeg mogelijk Interface Control Documents (ICD&#8217;s) op en leg daarin ook het wijzigingsproces vast, niet alleen de technische specificaties.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Hoe ga ik om met emergent gedrag dat pas zichtbaar wordt tijdens integratie of operatie?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Emergent gedrag is nooit volledig te voorspellen, maar je kunt de impact ervan beperken door integratiescenario&#8217;s en operationele use cases vroeg te modelleren. Voer integratietests uit op system-of-systems-niveau, niet alleen op deelsysteemniveau, en zorg voor een feedbackmechanisme waarmee operationele ervaringen terugvloeien naar het engineeringproces. Een MBSE-aanpak helpt hierbij omdat relaties en afhankelijkheden expliciet zichtbaar zijn.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Hoe manage ik de samenwerking met partijen die hun eigen systeem niet willen aanpassen?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Dit is een organisatorisch en bestuurlijk vraagstuk dat net zo belangrijk is als het technische ontwerp. Zorg voor een duidelijke governance-structuur met afgesproken escalatiepaden en besluitvormingsbevoegdheden op system-of-systems-niveau. Gebruik gestandaardiseerde interfaces en open protocollen zodat je zo min mogelijk afhankelijk bent van bereidheid tot aanpassing bij individuele systeemeigenaren. Bij het acknowledged type system of systems is een onafhankelijke systeemintegrator met mandaat vaak onmisbaar.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Is MBSE verplicht voor systems engineering op een system of systems, of kan ik ook met documenten werken?            <\/h3>\n            <p class=\"seoaic-answer\">\n                MBSE is niet verplicht, maar documenten schieten structureel tekort zodra de complexiteit toeneemt. Met losse Word-bestanden en spreadsheets verlies je snel het overzicht over relaties, traceability en de impact van wijzigingen. Je kunt starten met een lichtgewicht dataplatform dat relaties en traceability centraal stelt, zonder meteen te investeren in zware MBSE-tooling zoals Cameo. De sleutel is dat je eisen, interfaces en verificaties met elkaar verbindt in \u00e9\u00e9n centrale omgeving.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Hoe zorg ik voor traceability als deelsystemen door verschillende organisaties worden ontwikkeld?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Spreek bij de start van het programma af welke traceability-eisen gelden voor alle deelnemende partijen en leg dit vast in een overkoepelend systems engineering management plan. Gebruik een centrale omgeving of gedeeld platform waar alle partijen hun eisen, functies en verificaties aan kunnen koppelen, ook als ze intern andere tools gebruiken. API-koppelingen tussen tooling maken het mogelijk om traceability te handhaven zonder dat elke partij zijn eigen werkwijze volledig hoeft aan te passen.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Wanneer is een system of systems aanpak eigenlijk niet nodig?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Een system of systems aanpak is niet nodig als alle componenten van een systeem onder \u00e9\u00e9n eigenaar vallen, in \u00e9\u00e9n ontwikkeltraject worden gebouwd en als \u00e9\u00e9n geheel worden beheerd. Zodra er meerdere eigenaren, onafhankelijke levenscycli of externe systemen in het spel zijn die je niet volledig kunt controleren, is een system of systems aanpak echter onvermijdelijk. Het vroegtijdig herkennen van dit onderscheid voorkomt dat je een te simpele engineeringaanpak kiest voor een fundamenteel complexer vraagstuk.            <\/p>\n        <\/div>\n        <\/div>\n","protected":false},"excerpt":{"rendered":"<p>Een system of systems combineert onafhankelijke systemen tot \u00e9\u00e9n geheel. Ontdek hoe systems engineering dit beheersbaar maakt.<\/p>\n","protected":false},"author":1,"featured_media":3888,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3738","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/posts\/3738","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/comments?post=3738"}],"version-history":[{"count":1,"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/posts\/3738\/revisions"}],"predecessor-version":[{"id":3816,"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/posts\/3738\/revisions\/3816"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/media\/3888"}],"wp:attachment":[{"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/media?parent=3738"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/categories?post=3738"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/datastorms.eu\/nl\/wp-json\/wp\/v2\/tags?post=3738"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}