Voor en nadelen (spatieel) gedistribueerd

Transcriptie

1 Voor en nadelen (spatieel) gedistribueerd Centraal Dynamische regelbaarheid Gedistribueerd Communicatie hogere systeemlagen Communicatie lagere systeemlagen Fouttolerantie Faalgedrag Schaalbaarheid Complex systeem (aantal onderdelen) Omgevingscondities elektronica Kosten Balans niet echt attributief en Communicatieaspecten strijdig Complex systeem beheers(traceer)baar met model-based analyse liefst binnen Standaardisaties high tech equipment dag presentatie Protonic/Technobis 1

2 Duiding slide 1: *Gedistribueerd lijkt gunstiger (meer rood) maar kosten, communicatie over lagere systeemlagen, zwaardere omgevingscondities elektronica en systeemcomplexheid nemen toe *Strijdige aspecten in communicatie over systeemlagen zal niet alleen via communicatiegedragsmodellen onderzocht moeten worden maar ook via gedragsmodellen van het fysische (primaire) proces (spatiele verdeling en dynamische relaties) *Complexere systemen: vaak verschillende ontwerpdiciplines over verschillende bedrijven: beheers(traceer)baar met model-based analyse maakt STANDAARDISATIE in gebruikte modellen nodig

3 Meer gedistribueerd = complexer systeem (niet in het echt te prototypen) Requirements Analysis & Design Maar zo iteratief binnen: Standaardisaties Implementation Deployment Niet zo iteratief Validation high tech equipment dag presentatie Protonic/Technobis 2

4 Duiding slide 2: *Meer gedistribueerd is naar onder een meer complex systeem, ook het aantal stakeholders (belanghebbenden bij een product) nemen tegenwoordig toe, dus naar boven neemt de systeemcomplexiteit ook toe *Minder mogelijkheid om in het echt te prototypen *En nogmaals: Complexere systemen, vaak verschillende diciplines over verschillende bedrijven maakt STANDAARDISATIE in gebruikte modellen nodig (verliezen van gegevens in overdrag van modeldata)

5 Top-down systeem (data)model analyse 25 jaar terug gestart met Yourdon en Hatley/Pirbhai (real-trime) Nu combinatie Y&H/P, componenten en randvoorwaarden (over alle systeemlagen) Standaardisatie ontwikkelingen DoDAF Architectual Description Model (System Framework) architecture fundamental conception of a system in its environment embodied in its elements, their relationships to each other and to its environment, and the principles guiding its design and evolution. (ISO/IEC 42010) high tech equipment dag presentatie Protonic/Technobis 3

6 Duiding slide 3: *Yourdon en Hatley/Pirbhai is een gestructureerde (proces georienteerde) analysewijze die voor ons te veel richting een volledige functionele decompositie gaat dus implementaties van zo klein mogelijke sub-functies om systeemsynthese voor veel andere toepassingen mogelijk te maken. Niet-functionele aspecten zijn moeilijk in te brengen *Componenten zijn voor ons zowel (verschillende) hard en software componenten die gevalideerd (praktijk bewezen) zijn en voor verschillende systeemlagen *Niet alleen met het oog op standaardisatie maar ook door de redelijke overeenkomst met onze werkwijze: DoDAF

7 Top-down (data)model architecture (systemconcept) DoDAF (aangepast) Top-down mapping System/services viewtechn. standards view Hoe, waar en wanneer (implementatie) Niet functionele aspecten, reguleringen en standaards Operational view Systeemcontext Wat, waar en wanneer (functies) Randvoorwaarden Communicatie standaards Data beveiliging Kosten Energie efficiency Schaalbaarheid Fouttolerantie Faalkans Faalgedrag high tech equipment dag presentatie Protonic/Technobis 4

8 Duiding slide 4: *DoDAF opgezet vanuit militaire hoek vooral voor heel veel System of Systems maar door redelijke overeenkomst met onze huidige (globale) systeemstructuurbepaling toepasbaar *Per systeemlaag zowel de gewenste functies (WAT) en mogelijke (implementatie) oplossingen (HOE), maar ook spatieel verdeeld (WAAR) en dynamische aspecten (WANNEER) en dat in relatie met de randvoorwaarden *Performance en nauwkeurigheid zijn voor ons ook functionele (operational view) aspecten *Opzet operationele view geschikt voor MAPPING

9 Mapping voorbeeld vanuit IDEF0 model (DoDAF) IDEF0 is voor (operational) activiteiten en is process oriented Control Dynamisch en spatieel verdeeld Strategische activiteiten Middelen Logisch en spatieel verdeeld Taktische activiteiten Middelen (echte) Operationele activiteiten Middelen Zowel fysieke als data stromen high tech equipment dag presentatie Protonic/Technobis 5

10 Duiding slide 5: *Product(en) en productdata gericht, middelen (mechanism) geeft de koppeling naar de implementaties *Voorbeeld: Operationeel = primair proces, Taktisch = productie en onderhoud planning, Strategisch = verbeteringen *Hier al in de opzet rekening houden met Wanneer (dynamisch) en Waar (spatieel en logisch verdeeld) *Mapping Implementaties (System & Services) naar Functies niet te gedetailleerd maar wel STERK in overweging met: niet-functionele aspecten, regulereringen en standaards (randvoorwaarden) *Event-trace over de systeemlagen gedegen, state transitions binnen een systeemlaag globaal (details vanuit gedragsanalyse, zie verder SysML)

11 System-engineering & Bottom-up multi-domain gedragsmodellen DoDAF (ISO/IEC 42010) AP 233 (systeem engineeringsproces en datamodel ) SysML (Systeem Engineerings Modellerings Taal) SysML diagram Behavior diagrams Activity diagram Sequence diagram State machine diagram Use case diagram Requirements Structure diagrams Block def. diagram Internal block diagram Parametric diagram Diciplines & Tools (AP 233 data uitwisseling) high tech equipment dag presentatie Protonic/Technobis 6

12 Duiding slide 6: *AP 233 is vooral voor beheersing van de engineeringsprocessen t.a.v. uitwisseling van ontwerpgegevens over verschillende ontwerpdiciplines en gereedschappen (indien tools fabrikanten hieraan voldoen) *SysML komt vanuit UML maar heeft een minder sterk object georienteerd karakter en is niet alleen voor software realisatie maar wel voor software intensieve systemen *Wij beschouwen Requirements als het eerste resultaat uit de architectuurbepaling en de gedragsanalyses van potentiele implementaties (of vaste implementaties als het fysieke primaire proces weinig veranderbaar is) als terugkoppeling naar de uiteindelijke architectuur (abstracter systeembeschrijving) voor communicatie met alle stakeholders