-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy patharcadia-qna.html
1774 lines (1760 loc) · 199 KB
/
arcadia-qna.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en" class="no-js">
<head>
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-WCRD68P');</script>
<!-- End Google Tag Manager -->
<!-- Basic Page Needs
================================================== -->
<meta charset="utf-8">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel="icon" type="image/png" href="images/favicon.ico">
<title>Arcadia Questions & Answers</title>
<meta name="description"
content="Arcadia Questions & Answers.">
<meta name="keywords" content="">
<meta name="author" content="">
<!-- Mobile Specific Metas
================================================== -->
<meta name="format-detection" content="telephone=no">
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- Template CSS Files
================================================== -->
<!-- Twitter Bootstrs CSS -->
<link rel="stylesheet" href="css/bootstrap.min.css">
<!-- animate css -->
<link rel="stylesheet" href="css/animate.css">
<link rel="stylesheet" href="css/jquery.fancybox.css">
<!-- template main css file -->
<link rel="stylesheet" href="css/main.css">
<!-- responsive css -->
<link rel="stylesheet" href="css/responsive.css">
<link rel="stylesheet" href="css/latofonts.css">
<link rel="stylesheet" href="css/flag-icons.min.css">
<!-- Cookie content -->
<link rel="stylesheet" type="text/css"
href="//www.eclipse.org/eclipse.org-common/themes/solstice/public/stylesheets/vendor/cookieconsent/cookieconsent.min.css" />
<!-- Eclipse Foundation Google Tag Manager -->
<script>
(function (w, d, s, l, i) {
w[l] = w[l] || [];
w[l].push({
'gtm.start': new Date().getTime(),
event: 'gtm.js'
});
var f = d.getElementsByTagName(s)[0], j = d.createElement(s), dl = l != 'dataLayer' ? '&l='
+ l
: '';
j.async = true;
j.src = 'https://www.googletagmanager.com/gtm.js?id=' + i + dl;
f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'GTM-5WLCZXC');
</script>
<!-- End Google Tag Manager -->
<!-- Template Javascript Files
================================================== -->
<!-- Angular -->
<base href="/">
<script src="js/angular-1.7.8.min.js"></script>
<script src="angular/capella.js"></script>
<!-- jquery -->
<script src="js/jquery-3.4.1.min.js"></script>
<script src="js/helpers.js"></script>
<script defer src="https://kit.fontawesome.com/16cf99803e.js" crossorigin="anonymous"></script>
</head>
<body ng-app="capella" data-deferred-cloak>
<!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-WCRD68P"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->
<!--
==================================================
Header Section
================================================== -->
<ng-include src="'angular/blocks/header.html'"></ng-include>
<!--
==================================================
Intro Section
================================================== -->
<section class="hero-area services">
<div class="container">
<div class="row">
<div class="col-md-12 text-center">
<div class="block wow fadeInUp" data-wow-delay=".3s">
<section class="cd-intro">
<h1 class="wow fadeInUp animated" data-wow-delay=".4s">
Arcadia Questions & Answers<br>
</h1>
</section> <!-- cd-intro -->
<h2 class="wow fadeInUp animated" data-wow-delay=".6s">
Real life answers to real projects questions
</h2>
<p></p>
</div>
</div>
</div>
</div>
</section>
<!--/#intro_banner-->
<section>
<div class="container">
<p>This page collects questions raised by engineering teams of various domains and organizations, about to deploy <a href="arcadia.html">Arcadia</a>, or already deploying it and needing some support or clarification on the method and its use.</p>
<p>The answers given in the document are those that were proposed to engineering teams and applied by them in a coaching context, with little or no filtering. So they may not be relevant to any context or domain, neither are they accessible to any engineer, but at least they faithfully reflect real life concerns and the way they were addressed.</p>
<p><u>Warning:</u> These questions and answers are by no means self-sufficient to understand Arcadia and master its deployment. The reader is strongly recommended to read Arcadia reference documents before entering this one.</p>
<p><i>Jean-Luc Voirin ©Thales 2023</i></p>
<br>
<p style="margin-bottom:50px">The content of this page is also available in a PDF format: <a href="resources/arcadia-reference/Arcadia Q&A.pdf"><i class="fa fa-file-pdf"></i> Arcadia Q&A.pdf</a></p>
</div>
<div class="container">
<div class="row">
<ul class="nav nav-tabs">
<li class="active"><a href="#core-perspectives" data-toggle="tab">Core Perspectives</a></li>
<li><a href="#language-specifics" data-toggle="tab">Language specifics</a></li>
<li><a href="#model-building" data-toggle="tab">Model building hints</a></li>
<li><a href="#engineering-lifecycle" data-toggle="tab">Engineering Lifecycle</a></li>
<li><a href="#other-approaches" data-toggle="tab">Comparing to other approaches</a></li>
</ul>
<div id="myTabContent" class="tab-content">
<div id="core-perspectives" class="tab-pane fade active in">
<div class="accordion dropdown_content">
<div style="text-align:left">
<h2 class="title">Arcadia core Perspectives: Why and How</h2>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#3_1">
<h3>What are the objectives of the Operational Analysis?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="3_1" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Operational analysis is an essential contribution to the development of input data for defining the solution. It requires temporarily setting aside expectations about the solution itself, in favor of understanding users, their goals, and their needs, free from preconceptions about the solution.</p>
<p>However, its most important use is to stimulate a deeper understanding and definition of the need beyond the customer's requirements alone, achieved through a critical analysis of the formalization represented by the operational analysis.</p>
<p>Much of the added value of operational analysis lies in the "analysis" aspect rather than just capture or formalization, as it stimulates different perspectives, opportunities, constraints, and risks that might not otherwise have been taken into account. It can lead to proposing new capabilities that the system could offer, new services expected from it, as well as operational contexts and previously unforeseen risk situations.</p>
<p>For example, in many operational analyses, the first-level description is often not very different across missions. This is normal, but to be useful, it is necessary either to refine it to reveal differences at a finer level, which will feed the reflection (not recommended a priori), or to ask the question: "where are the differences, on which entities and activities do they occur, what constraints do they impose?" The difference may lie in constraints, non-functional properties, quantitative elements of scenarios, nature of information and time scales, etc., which will then be essential for the performance of the solution in real operational context.</p>
<p>Furthermore, the behavior of cooperative entities is often well described in operational analysis (although often generic, see above), but the behavior of other actors (threats, objects of interest, or non-cooperative actors in particular) is often not. However, there is a good chance that many of the constraints and expectations on performance come from the specificities of their behavior, their temporal evolution, their own goals and capabilities, etc. All of this must be captured and analyzed within the framework of operational analysis. </p>
<p>It is then essential, of course, to compare the analysis of the system's needs (and beyond) with this analysis and to evolve one or the other if necessary.</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#3_2">
<h3>What approach to follow for an Operational Analysis?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="3_2" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>A good way to start is to forget about modeling and instead focus on "telling a story" that describes the needs, expectations, and daily lives of end users and stakeholders.</p>
<p>This can be done using existing documents, observing stakeholders using current systems and means, or conducting interviews ("what is your job? Tell me about a typical day or mission. What makes your activities easier? What complicates or jeopardizes them?..."). At this stage, the formalization is limited to writing free text and checking that they are representative of the need.</p>
<ul>
<li>Establish the dimensioning situations and scenarios, the required capabilities to detect/face them and their dependencies, the induced constraints that will later influence the system</li>
<li>Put these capabilities into a time perspective (capability roadmap)</li>
<li>Define the operational doctrines, concepts, and roles of the actors, associated operational procedures</li>
<li>Evaluate new situations, along with gaps and discrepancies in the capabilities of the existing system relatively to the goals to be achieved</li>
<li>Identify opportunities that will then feed the definition of solution alternatives in response to this need</li>
<li>Define the conditions for the future operational evaluation of the solution to be developed: expected properties, constraints, operational scenarios, etc.</li>
<br><br>
</ul>
<p>Secondly, identify the key words in the previous material and determine for each how it could be represented in the operational analysis model (if relevant):</p>
<ul>
<li>missions and capabilities,</li>
<li>operational entities/actors and their links, </li>
<li>activities carried out by these entities and interactions between them, </li>
<li>operational information and domain model,</li>
<li>operational processes, temporal scenarios,</li>
<li>mission phases, operational modes, </li>
<li>engagement rules, etc., </li>
<li>programmatic vision (capability increments...).</li>
</ul>
<p>Finally, build an initial model on this basis and validate/extend it with stakeholders.</p>
<p>Here are the types of questions that can be asked during the development of the OA, which can either lead to completing it or deriving elements for the rest of the architectural definition (not exhaustive!):</p>
<ul>
<li>For each major activity and stakeholder (entity or actor), what makes it different from others? What makes it effective, what hinders it? What does it need to improve its effectiveness? What are the opportunities to provide other outputs, to enrich the service rendered - possibly with additional inputs?</li>
<li>For each activity, who else is likely to carry it out (entity, actor, other activity)?</li>
<li>For each interaction between activities (and entities), what could disrupt it? Under what conditions does it occur? Who else besides the identified destinations could benefit from it? Who else besides the identified sources could provide it, or provide complementary elements? And would that be desirable?</li>
<li>What disruptions are likely to occur in the activity or its inputs? What unintended uses could be made of its outputs?</li>
<li>What are the conditions of overlap or exclusion with other desired, imposed, and suffered activities? What is the link with any operational modes and states of entities? </li>
<li>What data or information, activities, actors or entities, interactions, etc., are most operationally important, according to the main points of view (value for the operational mission, criticality from a safety and security perspective...)? </li>
<li>What representative operational scenarios and processes describe the desired use of operational activities, interactions, etc., to contribute to associated missions and capabilities ("sunny days scenarios"), and how do they fit into time (timing of the mission, operations, expected system lifecycle, etc.)? </li>
<li>What unwanted operational scenarios and processes should be avoided ("rainy days scenarios")? </li>
<li>What constraints apply on each element (especially non-functional ones: performance, security, safety, operational importance, value...)?</li>
<li>What uncertainties, sequence disruptions, contextual changes, undesired states, degraded modes are likely to occur, and what consequences will they have on the previous elements?</li>
<li>How will the needs, constraints, contexts, situations, processes, etc., evolve over time?</li>
</ul>
<br><br>
<p>Important note: there are many other analysis and creativity approaches, such as CD&E, design thinking, approaches like C-K, and methodological approaches supporting enterprise architectures such as NAF V4, which would be useful and which the analysis of OA does not replace (and which I also recommend considering). But on the one hand, they are complementary and do not cover the same needs or the same scope of reflection as Arcadia, and on the other hand, their data should mutually nourish each other with that of OA.</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#3_3">
<h3>How to use the Operational Analysis for system needs analysis?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="3_3" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Based on operational analysis (OA), system needs analysis (SA) will define the contribution of the solution (referred to as the "system" hereafter) in terms of scope and expectations, particularly functional expectations. In other words, what services should the system provide to users to contribute to operational capabilities?</p>
<p>When conducting system needs analysis from operational analysis, the following questions should be asked:</p>
<ul>
<li>"Among the operational capabilities, which ones concern the system and/or its operators/users?"</li>
<li>"How can the system contribute to each operational activity (from OA)? What services (or functions) can be derived from it, whether they are expected from the system, users or operators, or entrusted to other external systems?" This may also generate new features to offer or different system contribution alternatives.</li>
<li>"For each interaction between operational activities, should/can the system be involved? In what way (displayed to the operator or treated internally...)?" This can also generate new services or expected functions.</li>
<li>"For each function that is expected from the system, how can each operational activity or interaction benefit from it? How can it constrain or influence this function?"</li>
<li>The same applies to operational processes and scenarios, states and modes... "How should the system assist users in each operational process, scenario, in each of their states and modes of operation? What constraints coming from these elements apply to the services it must provide?"<br>Study the conditions of overlap of several scenarios, states and modes, and how this overlap can alter them: new activities, need for parallel activities, separation of an activity into several... and associated functions. </li>
</ul>
<br><br>
<p>The separation between OA and SA, in addition to the benefits mentioned above, also allows the first major choices of engineering to be formalized and analyzed, particularly in the case of a new product or product line.</p>
<p>In these situations, several ways of meeting the same operational need may appear: different distributions of contributions between the system and its environment (use of other systems, for example), more or less advanced automation entrusted to the system, etc.</p>
<p>Engineering is therefore required to make an initial choice, not of design, but of delimiting the need allocated to the system.</p>
<p>It may then be wise to explicitly capture the different alternative terms, either through variability in the same SA, or in several SA candidates to be evaluated to select the most appropriate one for the context.</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#3_4">
<h3>How to verify the validity of your system/user allocation?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="3_4" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>A good definition of the human/system interaction is important, particularly regarding the users or operators of the system, both for communicating with the client and for preparing for integration, verification, and validation (IVV). To achieve this, you can ask yourself the following questions:</p>
<ul>
<li>Do the exchanges between operator/user and system accurately translate all the actions the user must take towards the system to carry out their operational activities? </li>
<li>For each user activity that uses expected system elements, does it provide the feedback the user needs?</li>
<li>Does the labeling of system and user functions accurately reflect the part that each of them takes on?</li>
<li>Are there multiple system implementation contexts (e.g. novice or expert user; or multiple levels of automation...)?</li>
<li>In which cases does the user initiate the interaction, and in which does the system initiate it (e.g. alert, end-of-task notification...)? What information should the system present in the latter case?</li>
<li>Between two interactions with the system, does the user need to make a decision that will condition the rest (in which case, it may be good to display it as an exchange between two operator functions, to make the Functional Chains or scenarios more meaningful)?</li>
<li>Can the user be interrupted and resume their activities later, and if so, are there any constraints? In this kind of case, it would be preferable to divide the operator activity into several functions...</li>
<li>Is the level of description of user activities and interactions necessary and sufficient to define and execute the verification/validation procedures?</li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#3_5">
<h3>Logical Architecture or Physical Architecture, do you need both ?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="3_5" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>In some (mainly software oriented) modelling approaches, what is called a "logical" architecture is a definition of (software) components and assembly rules, while "physical" architecture is a description of one or more deployments of instances of these components, on execution nodes and communication means.</p>
<br><br>
<p>This is not the case in Arcadia: the major reason for logical architecture (LA) is to manage complexity, by defining first a notional view of components, without taking care of design details, implementation constraints, and technological concerns - provided that these issues do not influence architectural breakdown at this level of detail.</p>
<p>By this way, major orientations of architecture can be defined and shared, while hiding part of the final complexity of the design, and without dependency on technologies. As an example, some domains or product lines have one single, common logical architecture for several projects or product variations.</p>
<p>In fact, logical architecture should have been named 'notional architecture', or 'conceptual architecture', but we had to meet existing legacy denominations.</p>
<br><br>
<p>Physical architecture (PA) describes the final solution extensively: functional behavior, behavioral components (incl. software) realizing this functional contents, and resource implementation components (incl. execution nodes).</p>
<p>Physical Architecture provides details what have not been taken into account at LA level, in order to give a description of the solution ready to sub-contract, purchase or develop, and to integrate. So all configuration items, software components, hardware devices... should be defined here (or later), but not before.</p>
<p>For this reason, maybe physical architecture would be better named as ‘finalized architecture’…</p>
<br><br>
<p>As you can imagine, then, for one logical component, we can often find several physical components, relation between logical and physical levels being one to many. Similarly, functional description of component is notional in LA, and detailled enough in PA so as to sub-contract it.</p>
<p>Consequently, for example, it is much easier to start defining an IVVQ strategy or a product variability definition, on the limited number of functions and components mentioned in LA, to quickly evaluate alternatives and select best ones. Once this is done, the former definition can be checked, refined and applied to the fully-detailed description of PA.</p>
<p>For the same reason, once they have finalized their physical architecture, many people feel the need to synthetize it in a more manageable and shareable representation, grouping some components and functions, hiding others, etc. Which is simply building a posteriori their initially lacking logical architecture!</p>
<p>However, if really the level of complexity does not require two functional levels for the description of the solution, then the following recommendations should be followed:</p>
<ul>
<li>If an implementation view is not needed, then an LA is sufficient without a PA. </li>
<li>If an implementation view is needed, then it would be better to put the detailed functional description in PA to have a regular model (and in Capella, the viewpoints, query engines, and other semantic browsers will thank you).</li>
</ul>
</div>
</div>
</div>
</div>
</div>
<div id="language-specifics" class="tab-pane">
<div class="accordion dropdown_content">
<div style="text-align:left">
<h2 class="title">Arcadia language specifics</h2>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_1">
<h3>What is a Capability?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_1" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>A <b>capability</b> is the ability of an organization (incl. Actors & Entities) or a system to provide a service that supports the achievement of high-level operational goals. These goals are called <b>missions.</b></p>
<p>A mission uses different capabilities to be performed. A capability is described by <b>a set of scenarios, and functional chains</b> (or <b>operational processes</b> in operational analysis), each describing a use case for the capability.</p>
<p>In Arcadia, there are operational missions and capabilities in OA (Operational Analysis), as well as system missions and capabilities (including users) in SA, LA, and PA (System Need Analysis, Logical, Physical Architecture). An expected operational capability of an actor should, if the system contributes to it, be derived (via traceability links) to one or more system capabilities in SA.</p>
<p>In Capella, there should also be missions in both OA and SA, as provided for by Arcadia.</p>
<br><br>
<p>To understand what the concept of mission and capability covers, we can use the analogy of an employee in a company:</p>
<ul>
<li>The company assigns a <b>mission</b> to the employee (often summarized in the job title).</li>
<li>The company ensures that the employee has the required <b>capabilities</b> to fulfill this mission (their skills, as listed on their CV).</li>
<li>The employee performs daily <b>activities</b> (analogous to functions or operational activities), which are carried out by applying <b>processes</b> and procedures (functional chains or scenarios). </li>
<li>Just as a (hiring) job interview validates the required skills, IVV will verify the capabilities of the solution. </li>
<li>We can see that capabilities do not represent everything an engineer can do in their daily work; this falls under operational activities or functions, depending on whether we model in OA or SA, LA, PA. </li>
<li>Therefore, Capabilities have more "added value" than activities or functions, and are directly related to a goal. This is why there are generally a limited number of capabilities in the model, and why they structure IVV, i.e. the adequacy of the system to the client/user's needs. </li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_2">
<h3>Leaf functions, parent functions?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_2" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>The expected behavior of the system or a component is described in Arcadia by the functional definition constituted by the dataflow (functions, functional exchanges, functional chains and scenarios, modes and states, exchanged data).</p>
<p>A function is fully described by its textual definition (and/or the requirements associated with it), its possible properties or attributes and constraints, the data it needs as inputs and those it is responsible for providing as outputs, as well as its implications in the functional chains and scenarios that involve it: functional exchanges involved, definition (textual) of the function's contribution in the chain or scenario ('involvements' in Capella).</p>
<br><br>
<p>This functional definition must be made at the finest level of detail necessary for understanding and verifying the expected behavior. It is the functions at this level of detail (called "leaf functions") that are allocated on the components and that define their behavior.</p>
<p>For convenience, both to offer a more accessible level of synthesis and representation, and to structure the presentation of the functional analysis, these leaf functions can be grouped into more synthetic parent functions. But these parent functions have only a documentary role (by categorizing the leaf functions): the reference remains the leaf functions. For Arcadia, they alone carry the definition and behavioral analysis of the architecture. </p>
<p>For example, a functional chain that would pass through a parent function itself instead of its leaf functions would leave a major ambiguity in the model regarding the role of each leaf function and its expectations (data to be produced, contribution to the chain, etc.).</p>
<p>Therefore, in a finalized state of the modeling, all leaf functions should carry the functional exchanges involved and ideally be each involved (as well as its exchanges) in at least one functional chain or scenario.</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_3">
<h3>Functional exchanges only on leaf functions?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_3" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Most modeling tools offer (mainly) a top-down construction approach based on decomposition (of components, functions), and the delegation of links connecting the previous elements at each level of decomposition. For example, first-level functions will be defined, connected by exchanges, then sub-functions will be inserted "into" each function, and a delegation link will be placed between a sub-function and the end of each exchange connecting the mother function to its sister functions.</p>
<p>In addition to the added complexity if a sub-function needs to be moved from one level to another, or if exchanges need to be added from the sub-functions, experience shows that this approach is neither the most natural nor the most common. For example, when modeling textual requirements, each of these requirements will result in the creation or enrichment of leaf functions, and exchanges will naturally occur between these leaf functions. One may then want to group these leaf functions into parent functions, but without having to go back and recreate all the exchanges to link them to the first-level functions with delegation links at each level. This is rather a bottom-up approach, and most often a combination of both (middle-out) is used.</p>
<p>This is why Arcadia recommends that, in a finalized state of modeling, only leaf functions carry exchanges, directly between them and without delegation. Thus, in a bottom-up approach, it will suffice to group leaf functions into a parent function at as many levels as desired; in a top-down approach, it will suffice to create sub-functions and then move each exchange from the mother to the sub-function that will take care of it.</p>
<p>Arcadia and Capella then propose automatic synthesis functions, only in the representation, to display diagrams in which the exchanges of the sub-functions are reported on the parent function if it is the only one visible. Similarly, exchanges can be grouped into hierarchical categories, which allow a simplified representation of several exchanges of the same category into a synthetic pseudo-exchange*.</p>
<p><span><i>*Capella supports simple (and multiple) exchange categories, but does not yet support hierarchical categories.</i></span></p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_4">
<h3>How to distinguish Dataflow from its usage contexts?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_4" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>The dataflow describes all the inputs required by each function and its potential outputs. However, these outputs and inputs may not be constantly solicited or used in all the system usage contexts, as defined in particular by its capabilities. </p>
<p>Similarly, the functional dependencies in the dataflow (functional exchanges) indicate that a function may receive its inputs from several other functions that are capable of producing them, but not necessarily all at the same time. </p>
<p>Therefore, the dataflow describes all the possible exchanges between functions, which must not be questioned in the system operation (that's why it's immutable and cannot be modified). </p>
<br><br>
<p>Furthermore, the system is subject to variable usage conditions (or use cases), not all of which may require the full range of production capabilities and exchanges between all functions.</p>
<p>Thus, in one of these use cases (referred to as a context, often described in a capability), only a subset of the dataflow is valid and used. This is what is described by the functional chains and scenarios associated with the capability: which part of the dataflow is used in a given context, and how this subset of the dataflow is implemented. And that's why functional chains and scenarios are described separately from the dataflow itself, and depend on the context (capability) in which they are exercised. </p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_5">
<h3>How to use Functional Chains?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_5" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>In Arcadia, initially, a functional chain is intended to carry non-functional constraints, typically end-to-end, in a given context (capability):</p>
<p>A functional chain is a means to describe one specific path among all possible paths traversing the dataflow,</p>
<ul>
<li>either to describe an expected behavior of the system in a given context,</li>
<li>or in order to express some non-functional properties along this functional path (latency, criticality, confidentiality, redundancy…).</li>
</ul>
<br><br>
<p>In order to avoid any ambiguity, especially when allocating non-functional properties to a functional chain (latency, criticality, confidentiality level…), some rules should be defined and respected to precise the meaning of a functional chain contents.</p>
<p>As an example, let's consider the case of a latency that the functional chain must respect end-to-end:</p>
<ul>
<li>If it is a question of expressing a need (specification) for a delay between a source event and a consequence, then a ‘1 start - 1 end’ rule is sufficient and should be applied, otherwise there is ambiguity. </li>
<li>If it is a question of expressing the need for multiple consequences or multiple source events, then the interpretation rule of first or last arrival, etc. must be added (e.g. latency is specified between the first of the inputs, and the output, or the last of the outputs, or the first…). </li>
<li>If we want to express a latency holding property in these situations as a result of the design, then it must be true regardless of the intermediate inputs;
otherwise, if the actual latency depends on additional inputs, this must be specified, but FCs do not have the required expressiveness for the temporal axis, loops, etc., so in this case a scenario, a constraint, text, or a dedicated viewpoint should be used for this expression. </li>
<li>If we want to calculate latency by analyzing the model, either we use the simple cases mentioned above (‘1I/1O’ or ‘nI/1O’ or ‘1I/nO’ + conventions), or we must define the behavior of each function in addition (output/input dependencies, synchronizations between them, etc.), for example in the form of an extension – and the associated conventions and interpretation rules (model of computation?) must be defined.</li>
</ul>
<p>Obviously, I would recommend the simplest solution whenever there is no counter-indication to do so. </p>
<p>Note that this may require characterizing/classifying functional chains according to their uses and the associated conventions for each. </p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_6">
<h3>Should I use a Scenario or a Functional Chain?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_6" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Functional Chains Vs Scenarios:</p>
<p>Both can and probably should be used. Functional Chains (FC) are more appropriate to describing a “path” in the dataflow, either to better understand the dataflow itself, or to specify (often non-functional) constraints such as latency expectations, criticality for safety reasons (e.g. associated to a feared event)…</p>
<p>For time-related details, scenarios (SC) are better adapted, but they hide the overall context that dataflow describes.</p>
<p>When FC become complex (especially with several entries and outputs), then understanding their behavior may become tricky, and scenarios could be easier to understand: a rule of thumb could be “if you need to show how the FC behaves, by using your mouse or hands on a diagram, then consider using scenarios.”</p>
<p>Although it is true that scenarios and functional chains are two facets of the same concept, each represents it for a different purpose:</p>
<ul>
<li>FC: we see its context and the other available paths within a dataflow; it is rather intended to carry non-functional constraints of the "end-to-end" type;</li>
<li>SC: highlights the chronology, which is sometimes implicit or ambiguous in FC; can be defined at any level and be partial (i.e. "omit" parts of the FC). </li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_7">
<h3>Adding Sequence Flows in Data Flows or not?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_7" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Data flows are there to show dependencies between functions (data required for operation, data produced), especially in order to build and justify the resulting interfaces. So it is indeed "real" exchanges that must be considered and not just pure control without any underlying "concrete" exchange.</p>
<p>I think that trying to transform Arcadia data flows into activity diagrams (AcD) or EFFBD would be a mistake: they do reflect the essential initial objective of expressing the need and orienting the solution (architecture):</p>
<ul>
<li>express the "contract" or "operating instructions" of each function (what it needs to operate and what it can provide),</li>
<li>express the dependency constraints between functions (what F2 needs can be provided by F1, or F3),</li>
<li>and do so globally (not locally to a diagram, as in an AcD or EFFBD): the function is characterized by the sum of all its dependencies expressed in all the diagrams, and these must be coherent (which is visible and done through the notion of function ports).</li>
</ul>
<br><br>
<p>This contract or "user manual" of a function may include, as input dependencies, "activation conditions" indicating that the function can only be executed upon explicit demand: the characterization of exchange items as events can, for example, fulfill this purpose. Therefore, a functional exchange can also be activating, for example.</p>
<p>But this is absolutely not a sequencing link in the EFFBD or AcD meaning, a link that simply translates a precedence or execution anteriority; by the way, this often appears unnecessary or even harmful to impose while describing the need or orienting a solution, as it would be an over-specification issue, risking freezing constraints that do not need to be. </p>
<p>Let's take an example:</p>
<p><i>I can chain the oil change of Mr. Dupont's car after the changing of the coolant when it arrives at my garage because his engine is hot. As a result, I tend to put sequence flows between these two functions in this order.</p>
<p>But for Mr. Durand, who dropped off his car at the same time, his engine is cold when I take care of it after Mr. Dupont's, so I will first change the coolant before doing the oil change. So, pure sequence flows are "contextual" and do not reflect an "intangible" dependence between functions.</p>
<p>Moreover, if we look at the change of the coolant alone, we can hardly see what it would need as input from the oil change. On the other hand, we have overlooked (perhaps by focusing a little too much on control) an essential input, which is the engine temperature, and also the need for a function to control it, or even to cool down/heat up the engine beforehand…</p></i>
<br><br>
<p>Let us remember that Arcadia was designed for the description and verification of architectures, and not for directly executable processes. As a result, there are different needs and also limits to be put in place: for example, if we were to put a pure sequence link (without any data exchange) between two functions, and each one was allocated to a component located on a different processor, we would introduce an inconsistency in the definition of the architecture and interfaces: without "physical" communication between the two components, there is no way to impose the order of precedence described in this way.</p>
<p>However, it may be necessary to express - separately - the aspects of 'sequence in a given context'; the Arcadia functional chains and scenarios are there to express this aspect, without polluting the dataflow, by separating the concepts well. Pure sequencing information can be added here if needed.</p>
<p>A loop with multiple iterations can be represented, for example, in a scenario (sequence diagram), and even a pure sequence link can be used in a functional chain or operational process (being aware of the risk of inconsistency between sequence links and real interfaces, mentioned above).</p>
<p>Similarly, if necessary, a sequencing function that commands those to be chained (involving an exchange with each of them, of the activation item type) and one or more scenarios that express the behavior of this function in different contexts can be added, thus reflecting the required activation order in each context.</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_8">
<h3>How to specify values or conditions for exchanged data?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_8" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Reminder: Arcadia separately defines the nature (or type) of data that can be exchanged (between functions or between behavioral components) and the use that is made of them. </p>
<p>The data model describes a piece of data independently of any use: its composition (its attributes), its relationships, possibly non-functional properties such as the level of confidentiality for example (via associated properties or constraints). </p>
<p>The content of each exchange is described by the concept of Exchange Item, which groups (and references) several data to be exchanged as a whole, simultaneously and coherently with each other (for example, the three geographical coordinates and the velocity vector of a mobile). </p>
<p>Each exchange carrying an exchange item references it in turn in the functional dataflow (several exchanges carrying the same EI may reference it). But so far, only the nature of the exchanged data has been described, which details the dependency between the functions of the dataflow. </p>
<br><br>
<p>Most often, the need to specify that a data must take a particular value arises to describe the expected behavior in a given context, i.e. in a reference to an exchange of a scenario or a functional chain. In this case, it is the reference to the exchange mentioned by the functional chain or the scenario that will specify the value taken by each data mentioned in the EI*. </p>
<p>Another need also arises when it is necessary to describe a conditional behavior. This is the case for a 'control node' in a functional chain: the condition on the data is expressed on each 'sequence link' leaving the control node. </p>
<p>This is also the case for a 'control functional sequence' in a scenario: the condition on the data is expressed on each control functional sequence**. </p>
<p><i>*This reference is implemented, in Capella, in the form of a 'functional exchange involvement' for a functional chain, or a 'sequence message' for a scenario; the description of the value on the data can be defined in the 'exchange context'.</i></p>
<p><i>**In Capella, the description of the value on the data can be defined in the 'guard' of the 'operand' grouping the exchanges concerned.</i></p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_9">
<h3>How to represent a request with reply in the functional flow?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_9" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Let's imagine that we have one or more clients requesting data (or other information) from a server. At the functional level, we will have a "provide..." function allocated to the server component and a "request..." function allocated to the client component. </p>
<p>At the SA level, we can often limit ourselves to defining a single functional exchange from "provide" to "request" to represent the dependency between the functions, and nothing more. </p>
<p>In LA (and possibly in PA), the natural and most logical rule would be to create two functional exchanges:</p>
<ul>
<li>One with the request (e.g., the reference to the data) from the "request" function to the "provide" function</li>
<li>The other with the requested data from "provide" to "request"</li>
</ul>
<p>This ensures the readability of scenarios and functional chains, and characterizes the definition of inputs and outputs of each function.</p>
<p>These two exchanges and the associated exchange items (EI) could then be translated into a single behavioral exchange between the client and server (with a convention to be defined, such as the request being directed from client to server, which is consistent with scenario sequence messages and returns). The EI of the component would have an IN parameter, the reference to the data, and an OUT parameter, the data itself, and would ideally be connected to the EI of the functional exchanges.</p>
<p>If we want to save modeling effort and use only one functional exchange, we can use the IN and OUT of the EI to represent exchanges in both directions, with the following precautions (in this case, the convention must be described precisely as it is subject to interpretation):</p>
<ul>
<li>Either the functional exchange starts from the "request" function to "provide" to represent a query, and the EI has an IN "request parameters" and an OUT "request result"; this is consistent with the design & development view, as a message or request sent from the requester to the provider; this is what we would like to see on a scenario, with a sequence message and a return.</li>
<li>Or, in the same situation, the exchange starts from "provide" because it is the direction of data flow, but the convention needs to be defined and seems less natural.</li>
<li>Or we can use two exchanges to ensure the consistency of functional chains.</li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_10">
<h3>How many Input and Output ports for exchanges?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_10" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>In the Arcadia method, not only is it allowed to have multiple exchanges exiting from the same port, but it is even recommended, and even essential, in certain cases, and not just to simplify the work of the modeler (although it does contribute to this): </p>
<p>By definition of a function, output ports express what it is capable of producing, independently of its uses (and thus of the number of uses). </p>
<p>For example, a GPS localization function is capable of providing a position. This position can, depending on the case, be used by one, two, 10... other functions, and this is not the concerns of the localization function. It is out of the question to define as many output ports as there are potential users, because that would mean that its definition would depend on the number of its users and would have to be modified every time a new one arrives... </p>
<p>Therefore, in this case, it has one output port, and only one. Each use of this position will result in a functional exchange between this output port and a port of the function that needs it. </p>
<br><br>
<p>Note that the remark also applies to input ports: they indicate what inputs the function needs to work; even if a function can receive data from multiple sources, if it processes them indiscriminately, then only one input port should be defined, which receives exchanges from various sources. </p>
<p>Linking several exchanges to a port means that they have no a priori relationship with each other: they are likely to occur at any time, independently of each other (such as requests from multiple clients to a server, for example, or sending emails by a server to multiple recipients), and the data transmitted a priori only share a common type (defined in the data model and the relevant exchange item), but they may be different instances. </p>
<p>On the other hand, to indicate that a position calculation function must combine a position from a GPS and another position received from an inertial unit, for example, this function will have two input ports (one for each source) carrying the same exchange item, which will group and describe the coordinates of the position. </p>
<p>If additional constraints are to be specified, such as simultaneous distribution of the same data to multiple recipients, or selective sending..., then dedicated functions for this purpose (split, duplicate...) are used. And if the same output is to be provided with different quality of service (e.g., a position accurate to within 10 meters every 10 seconds and another accurate to within 100 meters every second), two distinct ports will be defined, each with a constraint or a requirement on the quality of service.</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_11">
<h3>Can we allocate Functions to Implementation Components?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_11" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Arcadia does not provide for the allocation of functions to implementation components (IC), but only to behavioral components (BC). </p>
<p>It's not so much the allocation of functions to ICs that is problematic, but rather its consequences for exchanges: what happens, for example, if two functions communicate, one on an IC and the other on a BC? Through which ports? What is the concrete physical meaning of this? </p>
<p>Likewise, this makes the meta-model more complex (should functional exchanges be allocated to physical links?), as well as the exploitation of the model by analysis views (safety, security, RAMT, etc.). </p>
<p>In fact, in a number of cases, it may be more appropriate to ask why: for example, if power supply functions are placed in an IC for an electronic system-level model, is it because they need to interact with processing functions? If so, there is probably a behavioral component to define to manage them, interaction "protocols" to define (at the level of exchanges and behavioral components), and routing of these exchanges through physical links, etc.; placing the 'power supply' function on an IC would not solve all of this. And is it really useful at this engineering level? It all depends on how it is used; if the main reason is "documentary" (to remember the need for such a function in later development), attaching a constraint or requirement on the component concerned, qualifying them appropriately (voltages, currents, loads, etc.), would probably be simpler and more useful.</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_12">
<h3>Can Behavioral Components carry Physical Links?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_12" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>«In physical architecture, a Behavioral Component (BC) could be a hardware component. In this case, why can't we create Physical Links between BCs? With Capella, I'm forced to artificially create 2 BCs.»</p>
<p>«A Behavioral Component could be a hardware component.» Yes, in the sense that a functionality can be realized by a hardware component (e.g. generating a 28V power supply, managing memory – by a MMU...). This component is therefore a behavioral component.</p>
<p>However, even in this case, it is necessary to distinguish between the outputs of the functionality (electrical energy, memory segment addresses...) and the means of conveying them (cables or backplane, address bus...). It is therefore important to distinguish behavioral exchanges from physical links, and to be able to allocate the former to the latter.</p>
<p>Similarly, for components, the interest of distinguishing behavioral components from implementation components lies notably in different non-functional properties: for example, if I want to allocate software components to execution resources, I need to separately specify the resources required by each software component (BC), and the resources offered by each implementation component (IC): computing power, memory, etc., in order to compare them. And I may also want to define different ways of allocating the same BC to different ICs. To achieve all this, it is therefore necessary to have the two concepts separated. </p>
<p>Of course, simplifications are always possible, but it is necessary to make sure that this will not cause other problems, especially for the exploitation of the model by analysis viewpoints (safety, security, RAMT, etc.). It was therefore preferred to systematically create an IC in these situations, which sometimes does require "putting an IC around a BC," but makes the model more regular and easier to exploit. </p>
<br><br>
<p>« If my job is 'power supplies', then a transformer that takes 220V and transforms it into 12V is behavioral, and the physical links are on these components. I don't want to create an Implementation Component (IC or Node) for nothing and have a Behavior Component inside. What would you do for my example?»</p>
<p>I would distinguish:</p>
<ul>
<li>a "voltage converter" BC that receives and provides an electrical voltage (AC or DC, to be specified) through behavioral exchanges and carries out the transfer function,</li>
<li>and a "transformer" IC to which the electrical wires carrying the electrical voltage are connected as physical links. </li>
</ul>
<br><br>
<p>That way, I could distinguish between a case where the transformer is used as a voltage converter, and another case where the same transformer (IC) is used as a low-pass filter, for example (the distinction being made by the BC). </p>
<p>(By the way, we could also imagine mechanisms in Capella that would assist in this creation of ICs transparently, as is the case for ports today, created automatically as soon as an exchange is created).</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_13">
<h3>What benefits brings the Physical Architecture Representation?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_13" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>The expressiveness of languages such as basic UML or SysML (as available by default in COTS tools), which generally use 'Blocks' for all types of components and functions, is often insufficient, as is the tool support. For example: </p>
<ul>
<li>How to differentiate and represent software or firmware components from the boards, processors, FPGAs, etc. that support them, and visualize this allocation in a natural way? How to distinguish the same electrical transformer used as a voltage reducer or as a low-pass filter?</li>
<li>How to separately specify messages and physical, material links that carry them, while allocating them to each other?</li>
<li>How to model the routing of messages if they travel through multiple successive or parallel links, or a complex path?</li>
<li>How to visualize the functional content of components at the same time as the architecture?</li>
<li>How to represent the functional chains running through the system, and allocate properties to them (latency, criticality...)?</li>
<li>How to define the modes and states of the system? How to specify the behaviors associated with each state or mode and what they apply to? How to show mode changes in scenarios?</li>
<li>How to separate and represent the physical data formats coherently? For example, a position from an inertial unit via an ARINC bus, processed in software, then transmitted to the human-machine interface in Java and on an Ethernet bus via XDR... How to show the transport conditions of data sets?</li>
<li>How to separately represent the need and solution (as is done for requirements in SSS and SSDD/PIDS) and manage their configurations and different lifecycles?</li>
<li>The same goes for interfaces, preliminary ICDs, ICDs, and IRSs...</li>
<li>How to automatically generate documentation, taking these different lifecycle stages into account?</li>
<li>How to exploit models in order to articulate several levels of engineering?</li>
<li>How to practically perform impact analysis on all this, especially through automatic analysis of the model according to specialized viewpoints such as safety, RAMT, security, etc., if we do not distinguish the different concepts to consider and confront?</li>
</ul>
<br><br>
<p>For these various points (and many others), Arcadia and Capella, while not perfect or claiming to be exhaustive, offer proven solutions; among others: </p>
<ul>
<li>Separation of functional, behavioral structural, and implementation structural levels</li>
<li>Explicit allocation of one on the other</li>
<li>Separation of dataflow from functional dependencies and their uses in a given context (via functional chains and scenarios)</li>
<li>Addition of dedicated concepts for the articulation and consistency between these different views (functional paths and physical paths, configurations and situations of modes and states, etc.)</li>
<li>Separation and articulation between data (classes), transport units (exchange items), interfaces, exchanges, and ports</li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#4_14">
<h3>What is an Interface? How to use it?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="4_14" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Interfaces in the context of Arcadia and Capella are not classes, and the two concepts are clearly distinct:</p>
<ul>
<li>Classes ('Data' in Arcadia) are only used to define the data manipulated in exchanges between functions or components. Defining a method for a class in Capella would have no use in the model; it will never be explicitly called in exchanges between components, but only potentially in the internal software code of the component (outside of the Capella model).</li>
<li>Interfaces structure the services and means of interaction offered by the components:</li>
<ul>
<li>An interface is composed of exchange items (EI), each of these EIs defining an elementary service (or event, data flow...) that can be provided by one or more components and used (required) by other components. </li>
<li>An interface usually has a functional or semantic coherence: for example, for a multifunction printer, different interfaces can be used for the scanning function, the printing function, the photocopy function, printer management, etc. And the printing function interface will offer EIs (services) for choosing print parameters (paper size, orientation, color or B&W), printing the document, but also alerting in case of lack of paper or ink.</li>
<li>An EI "carries" a group of data (or parameters), each of which is characterized by its membership class and its name in the EI.</li>
<li>An interface is attached to a component port and contributes to defining its "user manual."</li>
</ul>
</ul>
<p>All of these concepts are not necessarily to be used in a given context and may - must - be adjusted to strict needs.</p>
</div>
</div>
</div>
</div>
</div>
<div id="model-building" class="tab-pane">
<div class="accordion dropdown_content">
<div style="text-align: left">
<h2 class="title">Model building hints</h2>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_1">
<h3>What are the frequent mistakes? How to avoid them?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_1" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>First, is Arcadia adapted to your scope and goals? Do you really target solution building, architecture definition & design and engineering mastering? Or are you mainly addressing better customer need understanding, focusing on customer side-capability operational deployment, programmatic issues… that he wants you to address (possibly together)?</p>
<ul>
<li>If stakeholders need mastering is the major expectation of your work, then an “architecture framework” based approach might fit better</li>
<li>If your purpose is to explore the problem space or the solution space at high level, for orientation or concept definition and experimentation, here again, Arcadia does not fully address this: it will possibly enter the game later</li>
<li>On the other side, if (architecture-driven) engineering is your focus, Arcadia targets engineering and architecture design, including operational and capability-related considerations that feed engineering – and here it is much better than architecture frameworks for that.</li>
</ul>
<br><br>
<p>Before starting, it would be useful to list main challenges and expectations of engineering, along with building a ‘maturity map’ of the subjects that your engineering will have to face, so as to orient modelling towards addressing low maturity subjects firstly, when and if appropriate. Driving modelling by its major uses and challenges is key for stop criteria and contents definition.</p>
<br><br>
<p>Some of the most frequent misunderstandings in applying the method lie in:</p>
<ul>
<li>Not clearly separating need (OA, SA) Vs solution (LA, PA) ; this leads to cluttering the need description with solution considerations, so it is costly to maintain, difficult to read and approve by the customer; it constrains the solution (because approved by the customer) and prevents from considering other alternatives;</li>
<ul>
<li>Therefore, take care to capture only need elements in SA especially, and keep it as small as possible.</li>
</ul>
<li>Considering that the functions describing the solution (e.g. in LA) are just a refinement of the need functions (in SA); this is usually not the case, especially if you reuse existing parts of the system, and might “corrupt” your SA or skew your LA ;</li>
<ul>
<li>So check consistency between need and solution by traceability links (e.g. between system functions and logical functions, between functional chains and scenarios on both sides…) but don’t try to strictly align both sides.</li>
</ul>
<li>Reducing the physical architecture to an allocation work of logical functions and components to hardware implementation components; if so, then your LA will probably be too detailed, thus costly to maintain and unnecessarily cluttered for most users; </li>
<ul>
<li>Instead, consider the LA as the introductory high level description that will help presenting and discussing on the major features and alternatives of the architecture, sufficient to reason on major architecture design choices, but not detailing the behavior too much, this being done in physical architecture (where interface definition could be finalized as well). Of course, this can be adapted to your own context, but beware the temptation to over-detail too early.</li>
</ul>
</ul>
<br><br>
<p>Other typical pitfalls follow:</p>
<ul>
<li>Wrong level of focus on concerns and parts of the system and model: most engineers focus on what they know, and detail this a lot, while neglecting new or low maturity parts. </li>
<ul>
<li>You should of course do the other way around, in order to raise possible problems and manage risk as early as possible.</li>
</ul>
<li>Addressing Reuse of existing components too early or too late: building a solution from parts without correctly mastering the real need, or at the opposite, designing a solution architecture from scratch, and then trying to insert existing stuff.</li>
<ul>
<li>To manage confrontation between existing systems contents and new expectations, when modelling practices are established, existing contents should be described in an initial PA, while new needs should be captured in OA and SA; so confrontation takes place in the LA: LA describes expected new architecture, and compares to physical existing assets; gaps are detected between LA and PA, and the physical architecture is modified accordingly to specify required evolutions.</li>
</ul>
<li>Considering the IVV issues lately, waiting for the definition of the solution to be complete.</li>
<ul>
<li>Capabilities are often a good way to drive and structure IVV and delivery strategy, while scenarios and functional chains will give you a prefiguration of test campaigns and test suites; the model will then help you identifying the required order of components deliveries, and test means contents, for example. This can be useful during bid phase as well, to size IVV activities and means, and also shape IVV strategy. Your design might also be positively influenced by taking IVV issues into consideration early, to make capabilities easier to verify, to split functional chains according to progressivity of integration, etc.</li>
</ul>
<li>Modelling without a clear vision of the kind of engineering problems that you want to solve with this modelling. The criteria for stopping the modelling and its orientation, as well as the guidelines given to each, depend on this answer. For example:</li>
<ul>
<li>If it is a question of justifying a development cost, a rough model is more than enough.</li>
<li>If the interfaces need to be justified, then the functional analysis and data must be detailed, but especially between the components (or actors).</li>
<li>If you need to secure the reuse of existing assets, the functional analysis must be fine-tuned because it is in the details that reuse incompatibilities are hidden.</li>
<li>For performance analysis, it is towards the functional chains and the superposition scenarios that we must look first, then the definition of the processing and communication resources, with a functional detail limited to the dimensioning.</li>
<li>For IVVQ, a homogeneous definition guided by scenarios and functional chains is required; the architecture must be broken down according to integration constraints, dependencies between components and separation of test chains (functions crossed by the tests).</li>
</ul>
<li>Regarding roles and responsibilities, just a strong warning: the risk exists that modelling be run beside “the real engineering stuff” rather than at the heart of it; this would result in possible mistakes in model and poor representativeness, but also in architecture and design decisions not relying on the model, thus weaker engineering and poor value for modelling.</li>
<ul>
<li>I would recommend that the architect, design authority and major authorities in system design be fully aware of model contents, and justifying their decisions based on it. This means not only monthly reviews, but day-to-day validation and appropriation of the model with the modelling team – or the architect could also be the lead modeler.</li>
</ul>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_2">
<h3>Why and how to use the Functional Analysis?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_2" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Arcadia, based on a component-based approach to architecture construction, relies on functional definition (dataflows + capabilities, functional chains, scenarios) to define and justify components, their interfaces, their expectations, and especially transverse behaviors that involve multiple components (functional chains, states, modes...).</p>
<ul>
<li>Components are created by grouping or segregating constrained functions
<ul>
<li>segregation/grouping constraints can both be functional and non-functional, but are all expressed through functional definition: safety-related feared events & hazards, reuse, product line, etc.</li>
</ul>
</li>
<li>Interactions between components are automatically deduced from functional allocation
<ul>
<li>via associated data flows that cross component boundaries</li>
</ul>
</li>
<li>Refinement is applied first to the functional analysis and the exchanges, and therefore automatically applies to components to which functions are allocated. Justification is done through functional traceability with the previous requirement model and requirements
<ul>
<li>via choice of precise behavioral design for each expected function, overall optimization between functions, etc.</li>
</ul>
</li>
<li>The behavior of each component is clearly defined by the scenarios that are allocated to it, as well as the functional content that justifies and specifies its interfaces and scenarios</li>
<li>Each component is described as a full-fledged subsystem,
<ul>
<li>with its scenarios, its interfaces,</li>
<li>as well as its functional content, </li>
<li>the functional chains that cross it,</li>
<li>the process for obtaining the data it provides and the use of the data it requires...</li>
</ul>
</li>
<li>In a product line approach, variabilities are defined on the functional level (optional functions or functional chains, for example), and their impact on components is visible, traceable, providing an architecture that is easier to design for the product line.</li>
<li>The overall behavior of the system is always visible, as are transverse functional chains
<ul>
<li>since they are based on functional definition, which remains visible and transverse to the definition of the components.</li>
</ul>
</li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_3">
<h3>How to define and justify Interfaces between Components?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_3" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>The basic idea of Arcadia for modeling interfaces between behavioral components is to rely on functional definition:</p>
<ul>
<li>precisely describe the expected behavior using functional analysis, through functional exchanges (FE) between functions that will be allocated to behavioral components</li>
<li>group the data to be exchanged together into an exchange item (EI), which reflects the need to exchange them in a coherent and simultaneous manner</li>
<li>reference the EI in the FE(s) that carry it between functions</li>
<li>describe the dynamic behavior using functional chains and scenarios using these functions and exchanges</li>
</ul>
<br><br>
<p>Once the functions are allocated to behavioral components:</p>
<ul>
<li>group and allocate the FE into behavioral component exchanges (CE) between behavioral components </li>
<li>do the same for functional and behavioral ports if necessary (especially to be able to reuse a "stand-alone" component in a library, for example, without external exchanges)</li>
<li>reorganize the exchanged data and EIs on the FE, if necessary, to construct the elements that will be exchanged between components (messages, commands, requests, or services, etc.) and allocate them to the CE</li>
<li>group and structure the EIs exchanged by the components, referencing them in interfaces that characterize the conditions of use of the component; allocate these interfaces to the ports of components exchanging these EIs</li>
<li>describe the dynamic behavior between components using scenarios that involve the aforementioned CE(s) </li>
<li>describe the communication steps, if applicable, through mode and state machines whose changes are mentioned in the scenarios; each machine being allocated to a component involved in the communication</li>
</ul>
<p>In summary, we synthesize and group the functional EIs into an interface (by simple reference), and similarly group the FE into a CE.</p>
<p>Finally, when behavioral components are allocated to implementation components:</p>
<ul>
<li>group and allocate the CE to physical links (PL) which will carry them between implementation components</li>
</ul>
<br><br>
<p>As a result, it is possible to have several EIs on a component exchange, originating from one or several FEs. However, if we want to indicate that sometimes we exchange one part, and sometimes another, and we want to show it in the CE, it is preferable to create several behavioral exchanges. In this case, it may be necessary to create categories for grouping the behavioral exchanges for documentary purposes. </p>
<br><br>
<p>Note: The software approach known as "component-based development" (CBD) favors encapsulation; that is, we try whenever possible to use a component by only looking at it from the outside, without having to know how it is made inside, and therefore without having to "open the box" to connect to internal sockets.</p>
<p>The ports and interfaces are there to group, abstract, and provide a view of the "user manual" of the component (at least for behavioral components); they should therefore provide the appropriate "natural" level of detail in the component behavioral exchanges. The detailed interactions should be seen at the functional level (via functional exchanges).</p>
<p>Similarly, according to the principles of CBD, we should only connect high-level components (not sub-components) to preserve the abstraction that high-level components constitute (being able to consider them as a black box). The ports of sub-components would therefore only be connected to the ports of the parent component through delegation links. However, experience shows that there may be exceptions, particularly in more physical or material domains. In these cases, direct links between sub-components are necessary. </p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_4">
<h3>Should we use textual requirements or models?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_4" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Textual requirements are, for most customers, the traditional and most used way of specifying their needs (note that more and more customers use and require models as well). So they cannot and should not be discarded in our process, at least as an input for our engineering and a source of justification links towards IVV for Customer.</p>
<p>However, textual requirements suffer from weaknesses that may impact engineering and product quality:</p>
<ul>
<li>They are possibly ambiguous, and contradictory or incoherent with each others, with no formalized language to reduce these ambiguities</li>
<li>Their relationships and dependencies are not expressed, and being implicit and informal, they may be wrong or contradictory</li>
<li>They cannot be checked or verified by digital means, in most cases</li>
<li>They are poorly adapted to collaborative building and reviewing, for the former reasons</li>
<li>The process of creating links to each requirement (for design, IVV, sub-contracting…) is unclear, without a defined method; the way to verify these links is undefined; the quality of these links proves to be poor in many cases (as discovered lately in IVV)</li>
<li>Textual requirements (alone) are not adapted to describing an expected end to end system solution (each of them only expresses a limited and focused expectation); they are not adapted to describe a solution</li>
<li>They alone can hardly be sufficient to describe subsystems need, including usage scenarios, detailed interfaces, performances, dynamic resource consumption, and more</li>
<li>...</li>
</ul>
<br><br>
<p>Models tend to solve these weaknesses, thanks to:</p>
<ul>
<li>Defining a formalized language, less ambiguous and shareable, digitally analyzable to detect inconsistencies</li>
<li>Bringing internal consistency thanks to the language properties and concepts (e.g. linking functions by data dependency, making them coherent with functional chains, allocating them to components, linking a required function to design architecture behavior implementing it, adding non-functional (NF) requirements such as performance or safety expectations on functional chains, etc.)</li>
<li>Explicitly describing and tooling the process to build, link, analyze model elements above</li>
<li>Relating all modeled elements to each other into one global view, thus providing means to check their coherency and consistency</li>
<li>Favoring collaboration by natural, functional structure, and means to confront different views (e.g. capabilities/ functional chains/scenarios, functions and dataflows, data and interfaces definition, modes & states, components, and more)</li>
<li>Describing need and solution separately, while providing justification and traceability links that can be semantically checked</li>
<li>Describing solution based on both functional/NF and structural descriptions, functional/NF one justifying structural definition (interfaces, performances, resources usage…)</li>
<li>Constituting a detailed components development contract (or subsystem specification), including all the former elements</li>
<li>Easing IVV strategy and justification by directly feeding test campaigns with capabilities, scenarios and functional chains, thus improving the quality and efficiency of IVV</li>
<li>...</li>
</ul>
<br><br>
<p>This leads, internally in our engineering practices, to using models as much as possible to describe both need and solution at each level, while complementing them with textual requirements, either to detail expectations (e.g. to describe what is intended from a leaf function behavior), or to express requirements that are not efficiently expressible in the model (e.g. environmental or regulation constraints).</p>
<p>However, it should be noted that:</p>
<ul>
<li>Not all requirements can be represented in the model. </li>
<li>Those that can do not exempt a textual description of these elements themselves, which becomes more expressive and flexible than the model's formalism. This description may or may not be formalized as a 'textual requirement' object in the traditional meaning.</li>
<li>Requirements that can’t be represented in the model must still be managed, allocated, and traced between systems and subsystems/SW/HW, AND linked to the engineering elements on which they relate (other requirements of different levels, tests, etc.).</li>
</ul>
<p>But the key point is to treat these requirements according to their real usage in engineering, and governed by the model whenever possible (for structuring, navigation, justification, etc.). </p>
<p>Therefore, internally, requirements will be mostly model elements, and complementary textual ones. Both will be related to customer requirements by traceability links, allowing justification from test results up to customer requirements, through model elements verification.</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_5">
<h3>Which requirements can be model-based?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_5" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Requirements that can be formalized as model elements (hereafter referred to as model requirements) include requirements of the following types:</p>
<ul>
<li>Functional, interfaces, performance: the most common, allocatable to elements of architecture model, verifiable by IVV scenarios (demonstration and tests).</li>
<li>Structural (SWaP (size weight & power), distribution on geographical sites, recurring cost, number of copies, etc.): allocatable to elements of architecture model, often verifiable by inspection.</li>
<li>Non-functional but related to architecture (safety, security, availability, etc.): allocatable to architecture model elements, in the expression of need (feared events, threats, essential goods, critical functions, etc.) and solution (safety and security barriers, redundancies, degraded modes, etc.), and verifiable by model analysis.</li>
<li>Non-functional but verifiable by analysis or demonstration (simulation, formal proof, analysis by specialty tools including safety, security, availability, etc.): allocatable to specialized models supporting analysis or demonstration.</li>
</ul>
<br><br>
<p>Requirements that can hardly be modeled are for example:</p>
<ul>
<li>Regulatory requirements: compliance with standards, etc. They can be transmitted to subsystems, but most of the time verified by inspection, therefore linked to little or no engineering assets.</li>
<li>Contractual requirements: supply deadlines, maintenance duration, repair deadlines, etc. ditto</li>
<li>Environnement-related requirements : temperature range in operation or storage, resistance to salted spray, etc. ditto</li>
<li>Requirements directly allocatable to subsystems and without impact on the system: to be dealt with at a lower engineering level</li>
<li>[Requirements that are modelable by nature (performance, safety/security, etc.), but whose current MBSE practices maturity does not yet allow to do so]: temporarily, they can have the same uses as modelable requirements.</li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_6">
<h3>Why use model requirements?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_6" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>There are at least three major uses for these model-based requirements, as well as complementary associated textual requirements:</p>
<ul>
<li>To build a solution that takes into account User Requirements (URs). Arcadia proposes to formalize/confront/connect them in OA/SA, and then to construct a solution traced with respect to this formalization; thus, everything happens in the model if they have been captured and formalized there.<br />Note: it is necessary to keep the possibility of directly linking model elements located in LA and PA to these URs: to have more accurate traceability, and thus to avoid too much detail in the SA if it was the only perspective that accounts for these URs, while increasing the number of URs that can be modeled. This also applies to so-called requirements which are more likely premature design elements.</li>
<li>To define a Verification and Validation (V&V) process that demonstrates the adequacy of the produced solution with these requirements.<br />What is actually verified is not these descriptions in the form of textual requirements, but the satisfaction of the expected capabilities, through scenarios and functional chains representing this need, in accordance with the entire model description (including these textual description elements).<br />The Arcadia approach consists of constructing test campaigns based on the capabilities/functional chains/scenarios, while explicitly specifying and ensuring the link between need and solution (which is not done in the traditional approach), which allows for checking the model elements and associated URs. Thus, we always remain in the model, and there are model/tests links, from which we deduce the UR-Tests links indirectly.<br />The justification of the solution with respect to URs is done, for model-driven requirements, by "indirection": we check the model elements (via tests based on the capabilities, functional chains and scenarios of the model); once these are verified, we can verify the associated user requirements, and we can generate justification tables, for example, UR-test results.</li>
<li>To define the realization contracts of subsystems. These are constructed from the physical architecture, and any impact and traceability analysis is also done in the model, which is specifying (the model elements are subsystem requirements (SSR)).<br />If the subsystem is also in a model-driven approach, then we remain in this context, and the SYS/SS traceability is done between SYS and SS model elements. Otherwise, we will generate documents or even requirements exports, under the same conditions as for the client SSS, as described above.<br />Note: the case of URs that can be directly allocated to subsystems and have no impact on the system should be considered. In this case, the simplest solution is to directly link these URs to the associated SS components in the PA.</li>
</ul>
<br><br>
<p>In these three uses, I do not see any reason to "take the requirements out of the model" for the engineering level concerned. So for me, the simplest and most productive solution is to manage these requirements (system requirements, sub-system requirements) in the model only, with the appropriate links to URs, which are themselves by default in the model.</p>
<p>This also has the merit of greatly simplifying everything related to reuse, variability in product line, versioning, branch reporting, configuration management, feeding inputs and models of specialty engineering, etc. (all sources of complexity that are still ahead of us...).</p>
<p>The essential point here is to consider and treat these requirements according to their real use in engineering, and to govern them by the model whenever possible (for structuring, navigation, justification...).</p>
<p>To summarize the global approach:</p>
<ul>
<li>When analyzing need (SA, maybe OA): “translating” <strong>customer/user requirements</strong> (UR) to model elements, you link UR with SA model elements when appropriate; these model elements constitute the <strong>system requirements</strong>, along with complementary textual requirements if needed (linked to model as well)</li>
<li>When defining the solution architecture in LA and PA, you create links between LA/PA functions and SA functions’ (and functional chains, and other SA elements). You can consider that this brings indirect links between UR and LA PA components (component to LA PA function, to SA function, to UR)</li>
<li>In some cases, you may directly link LA PA model elements to system or user reqs, if those reqs deal with physical considerations (eg the kind of operating system required by the customer, or environmental conditions…); it is better in this case not to artificially links these textual reqs to SA functions, which would create meaningless need functions, but rather to only link them to appropriate PA objects</li>
<li>PA model elements, allocated to sub-systems or components, constitute most <strong>sub-system requirements</strong>; you can add some complementary sub-systems textual requirements to your PA (linked to model elements),</li>
<ul>
<li>either to detail PA elements expectations (e.g. to describe expectations on a physical function)</li>
<li>or to “split” a system req to allocate parts of it to different subsystems</li>
<li>or to add reqs associated to system design choices.</li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_7">
<h3>Where to link textual requirements with the model?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_7" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>Here, we mainly consider the requirements received from the client (user requirements, UR), assuming that the main uses of the model are:</p>
<ol>
<li>defining the interfaces between subsystems, </li>
<li>defining the functional expectations of each subsystem, </li>
<li>making overall design choices,</li>
<li>driving the system IVV.</li>
</ol>
<br><br>
<ul>
<li>If a requirement concerns the architecture (e.g. realization technology, constraints on a specific component...), then link it to the LA or PA, not necessarily to the SA.</li>
<li>If a requirement impacts only one subsystem, it is preferable to link it only in the subsystem model (or documents), unless it obviously impacts the system-level SA functional analysis.</li>
<li>If a requirement can be fully verified at the IVV level of a subsystem, same as above; unless it obviously impacts the system-level SA analysis.</li>
<li>If deemed really necessary, these requirements can be linked not only to the subsystem model but also allocated to the relevant component representing the subsystem in the system model (in LA or PA, but not in SA).</li>
<li>If the requirement concerns a functional analysis expectation, several cases are possible:</li>
<ul>
<li>some requirements can only be expressed on a functional chain (e.g. end-to-end latency constraint, cyber-security...), or on a scenario</li>
<li>some requirements are specific to a function independently of its uses (e.g. criticality level), or common to all its uses (explaining and detailing the function behavior, thus detailing the function name)</li>
<li>some requirements are specific to the use of a function in a given context - capacity, functional chain, scenario, or even mode or state - (e.g. function behavior different depending on whether the system is in manual or automatic mode), and thus should be attached to the use of the function in the functional chain or scenario (the "involvement" in Capella).</li>
</ul>
<li>If the requirement concerns data to be exchanged, or a condition of interaction between two functions..., it would be more accurate to link it to the exchange, since it is likely to carry the definition of the associated data, rather than to link it to the source or destination function of the exchange (which allows in particular to find the requirements mentioning a data by going back from it to the EI and FE that carry it and from there to the associated requirements).</li>
</ul>
<br><br>
<p >What is important is that in a finalized engineering, every requirement is allocated either to a model element, to another engineering element (simulation, study...), or to a subsystem. It would be useless and artificial to constrain or overload the SA to account for requirements that do not constrain either the functional aspects or the system's interactions with the outside world (this may be better understood with an example like "the processors used must be octo-core Core I7 ").</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_8">
<h3>Does the system appear in the operational analysis or not?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_8" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>It is important to understand the purpose of the operational analysis and when it comes into play in engineering. The operational analysis is particularly useful when seeking to best satisfy a client's need, without having an imposed system scope, or by seeking innovative ways to satisfy this client's need.</p>
<p>The OA should not mention the system, as it aims to understand the client's need without any assumptions about how the system will contribute to it; this is to avoid too quickly restricting the field of possibilities (which will only be done in System Analysis, by deciding at this level what will be requested from the system and what will remain with the operators and external systems).</p>
<p>The observation is that when the system is mentioned in operational analysis, potentially interesting alternatives in system definition are already excluded.</p>
<p>Let's consider this example: the client's need is to have means to hang a painting on the wall, the trend is to formulate the need as "how to use my drill system, what to do with it". As a result, we find the system (drill) in the operational analysis, so the game is over, no smarter alternative is possible. Operational analysis is not very useful, as it duplicates the role of System Analysis.</p>
<p>What Arcadia (and Architecture Frameworks such as NAF) suggests is to restrict Operational Analysis to what the client and stakeholders need to do: the (operational) capacity to have a localized fixation point in a specific location. Therefore, I am not yet talking about a drill in the operational analysis, but I am trying to analyze the need well: should the fixation be reversible? can the wall be damaged? should the position of the painting be adjustable? what will be the maximum weight of the painting? what will be its size? will it have to be placed and removed frequently? who will ensure the fixation, with what qualification?</p>
<p>From this Operational Analysis, Arcadia recommends a capability analysis, i.e., finding the different possible alternatives and comparing them: here,</p>
<ul>
<li>a hole + dowel + drill,</li>
<li>but also a self-drilling point and a hammer,</li>
<li>or an adhesive hook or a contact glue…</li>
</ul>
<p>We analyze the various solutions (compromise facilitated, price, user training...) in subsequent candidate System need Analysis and early Architecture perspectives (SA/LA/PA), and choose the best (best compromise). Suppose it is the drill and dowel; we can now define the system, its system capabilities (fix a dowel) and its functions in final System Analysis (drilling, choosing the diameter, controlling the depth...).</p>
<p>Revisiting the OA with each evolution of technologies can then allow us to propose new products or solutions.</p>
<br><br>
<p>Once again, focusing on the system in Operational Analysis can bias the analysis. Two examples (a bit caricatural):</p>
<ul>
<li>If the system under engineering is an execution platform (multi-processors or private cloud, for example): if we focus the Operational Analysis on the platform, we naturally define how each actor interacts with it - at the risk of forgetting that the software applications hosted by the platform also communicate (first) with each other, and that the platform has a role to play in this communication.<br />The approach proposed by Arcadia or the Architecture Frameworks would consist, in Operational Analysis, of analyzing for each actor with whom and why they communicate - and thus, the "direct" communication between applications actors would appear. By building the System Analysis afterward, we should wonder how the platform system can support this inter-application communication, and we would thus reveal communication services provided by the platform - which would also allow us to properly characterize and size the needs of applications (e.g., broadcasting, events, microservices, etc.).</li>
<li>Another example: a communication management system in an airliner: if the initial OA had been done by integrating the system (wrongly, as you understood ;-)), it would describe the links between the system and the actors (airlines, air traffic control, airport, weather services, etc.), and these links would be characterized by frequencies, protocols, etc.<br />In this case, when moving to the SA, the added value of the SA compared to the OA is often not seen - rightly so. Furthermore, there are still no means to dimension the complexity of the operator load (e.g. during final approach) or data exchanges.<br />The OA must therefore be done, temporarily forgetting the radio management system and focusing on the activities of the actors (airlines, ATM, airport, etc., but also crew) and the associated exchanges; in doing so, it highlights the nature of the exchanges (flight plans, weather files, etc.), the flight phases in which these exchanges occur... and the workload induced for the pilots.<br />When moving to the SA and introducing the communication management system, its contribution to these exchanges is defined, which this time are dimensioned and time related; this makes it possible to establish a profile of system performance. And one can also see what is traditionally outside the system domain (e.g. voice communication), and which could inspire functional enrichment of the system (e.g. digital messaging replacing or complementing voice communication).</li>
</ul>
<br><br>
<p>Another question and scenario: how to talk about maintenance in OA without taking into account the thing being maintained?</p>
<p>Taking into account the thing being maintained does not mean representing it as an actor: one can perfectly well describe, at the OA level, the maintenance processes of the system under engineering, describing only the maintenance team activities: dismantling, bench testing, fault localization, software and firmware updating, configuration verification, etc.</p>
<p>Then, in the SA, we will try to deduce the requirements on the system, by formulating questions derived from the OA: "how should the system be designed to be easily dismantled? What enabling systems are needed to test it, and what functionalities should they have? What observability capabilities must the system have to assist in fault localization? What software updating means? etc.</p>
<p>Some of this will translate into SA as requirements allocated to the system, and some as required functions of the system (e.g. download, version supply, observability or alerting reporting functions...).</p>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_9">
<h3>Operational Analysis: Where to stop?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_9" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p >DO NOT include the system in the OA, as indicated above. The OA focuses on the users; the scope and expectations of the system will be defined and analyzed in System Needs Analysis (SA).</p>
<p>Set the boundaries of the coverage area: this is not easy, but otherwise you will end up modeling the entire organization of the client or users. The question to ask is like, "will this concern the users of my system, the systems interacting with them and with it, etc.?"</p>
<p>Do not forget to look for discriminators, priorities, criticality, etc., which will guide the system's choices and compromises in the following perspectives – along with value-driven engineering.</p>
<p>It is impossible and useless to formalize the <em>whole</em> operational material. It is sometimes better to capture it with organized or structured text and extract from it, to populate the OA model:</p>
<ul>
<li>Typical situations that will also be used for IVV, value analysis, cyber, etc.</li>
<li>Illustrative cases of opportunities, constraints, or threats</li>
<li>References to textual descriptions that provide all the detail and diversity of situations.</li>
</ul>
<p>The model is there to organize and help analyze, detail and illustratethe raw textual data, provide a representative and synthetic view, that can be manipulated and analyzed in a systematic way, and then be related to the rest of the analysis and definition (SA, LA PA, simulations, IVV, etc.). But not exhaustively.</p>
<br><br>
<p> Obviously, the consequences of such an analysis can be scary, fearing an inflation in the size of the OA model, on the one hand, and the prospect of having to translate all this into SA afterwards. Several suggestions or recommendations in this case:</p>
<ul>
<li>In many of the above cases, most operational situations fall into a limited number of generic patterns; the diversity of situations is reflected in particular expectations for each in a given pattern, via constraints, non-functional properties, feared or expected scenarios, on existing elements (functional chains, scenarios...), therefore not an inflation of the elements already present.</li>
<li>In other cases (as much as possible!), this will result in new needs or service opportunities on the system (and therefore to be captured in SA, and traced with respect to the elements of the OA that illustrate it, even if they are commented on by appropriate requirements or constraints)</li>
<li>And regarding the OA SA transition work, I think it also needs to be managed "economically": for example, an OA scenario representative of a situation that will need to be confronted in the design does not necessarily need to be translated into SA; it may suffice for future scenarios in PA illustrating the realization of the expected capacity to reference the OA scenario and the associated services in SA, linked to each other as indicated above.</li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">
<a class="accordion-toggle collapsed" data-toggle="collapse" data-parent="#accordion2" href="#5_10">
<h3>What’s the difference between Modes and States?</h3>
<span class="fas fa-caret-down txt_yellow" aria-hidden="true"> </span></a>
</div>
<div id="5_10" class="accordion-body collapse" style="height: 0px;">
<div class="accordion-inner">
<p>In Arcadia, Modes and States are similar in concepts and description, but bear different meanings and uses.</p>
<ul>
<li>A Mode is a behavior expected of the system or a component, in some chosen conditions.<br />Examples of modes for a drone: Autonomous flight, waypoint-driven path, remote-controlled flight; Collision avoidance active or not; take-off, en route, stationary flight (mission phases).</li>
<li>A State is a behavior undergone by the system or a component, in some conditions imposed by the environment.<br />Examples of states for a drone: Starting or On or Shutdown or Off; Available, or Degraded, or Failed/out of order; Day or Night; windy or still weather.</li>
</ul>
<br><br>
<p>The first important issues to address in architecture modeling for M&S, are mainly:</p>
<ul>
<li>Identifying system modes and states, their conditions of realization and the functional behavior that they allow or need (e.g. functional chains)</li>
<li>Identifying sources and nature of conditions for transitions</li>
<li>Defining contribution of each subsystem or component to these system M&S, and complementary “local” M&S to be supported by the component according to its internal behavior.</li>
<li>Checking that sources and contents of transitions are properly defined in interfaces (external and between subsystems or components), and that appropriate functions support generating these triggers and supporting expected actions</li>
<li>Checking that M&S state machines of various subsystems or components are coherent with each other (e.g. no deadlock or starvation in triggers…) – this is still to be tooled.</li>
</ul>
<p>Theoretically speaking, any trigger should be produced by a well-identified function somewhere in the system, and be carried by functional / components exchanges.</p>
<p>By the way, remember that Arcadia and Capella target <em>architecture</em> engineering, and not detailed [software] design: if complexity of M&S raises, this might (or not) mean that they describe detailed design rather than expected general behavior.
<p>For a more advanced “Modes & States engineering”, Arcadia and Capella introduce new concepts:</p>
<ul>
<li>A Situation is a combination of states and modes representing the conditions of superposition of these states and modes simultaneously at a given instant.<br />Example of a situation: (Autonomous or remote-controlled flight) AND Collision avoidance active AND Night AND windy AND Available.</li>
<li>A Configuration is a set of System or model items that are globally available or unavailable in a given mode or state. Each mode or state is described by an atomic configuration.<br />Example of configuration: collision avoidance->available, autonomous flight ->available, remote control link->available, localization sensor->failed</li>
</ul>
<br><br>
<p>A recommended approach to verify that architecture design is valid concerning expected behavior, taking benefit from these concepts, would be (simplified):</p>
<ul>
<li>Define expected configurations that should be valid in different conditions in operation (mainly defining capabilities, functional chains or scenarios that should be supported by the system in these contexts)</li>
<li>Define typical situations, representative of what could be expected or could happen in real operation (e.g. main kinds of component failures, main mode changes)</li>
<li>Compute the global configuration resulting of superposing the different atomic configurations brought by modes and states in each situation</li>
<li>Compare this result to each expected configuration</li>
</ul>
</div>
</div>
</div>
<div class="accordion-group">
<div class="accordion-heading">