Hi JFAvi8,
You’re addressing a very commonly asked question.
See Jean-Luc Voirin’s answer below extracted from Arcadia Q&A (Model building hints → How to engineer and model communication layers).
The way to model a system which includes communication layers (such as the 7 layers OSI model) is interesting, because it emphasizes the different scopes that different engineering teams have to deal with, and how they should articulate with each other.
Let us imagine a system in charge of supervising scattered installations on the Mars planet, environmental constraints requiring developing a new ruggedized, specific communication stack. Here, we consider the top level system engineering model.
- The top level system engineering team should usually:
- focus on the application-level processing and communication needs : collect status of installations, send them to a monitoring application, delivering appropriate human-system interfaces etc… A major goal is specifying this need to application software teams for example,
- also specify the underlying communication infrastructure to the communication engineering team, by describing what kinds of communications should be supported, with which performance and QoS constraints (see below),
- and integrate both, mainly focusing, at its high level, on operational, applicative scenarios and application level exchanges, the use of the communication means being implicit and hidden (provided that communication means had been validated separately before being integrated with application software).
- From an application (software) component engineering point of view, the component never has two different kinds of interfaces that cohabit: if you consider the software code of the application component, for example, it only communicates with other application level components, by sending messages, events, requests or so. It has no explicit call to low level communication API for example.
So what the software application team expects as a specification, only deals with
- application level exchanges,
- and possibly the kind of service to be used for each communication exchange (if not to be decided by software team).
Therefore, putting both application- and protocol-related interfaces on the application components would have no meaning.
- From the communication engineering team point of view, they have no need to get all the application level exchanges as an input, to define and build their communication stack; what they need is:
- the different kinds of communication services, styles and paradigms that are necessary in order to implement the expected behavior,
- expected quality of service for each service,
- some kinds of ‘communication performance profiles’ that will define how the communication infrastructure will be solicited (how many services of each kind per second, size of transported data, real-time and scheduling constraints, and so on).
This requires enriching the description of each application level exchange (or exchange item) in top level system engineering model, with complementary properties (such as required communication service or paradigm), and then synthesizing them so as to specify expected communication services.
The means to define the performance profiles is trickier, and depends a lot from the level of detail in the system engineering model, and the details of the dynamic behavior description. It might have to come from another separated (non Arcadia?) model, more dedicated to performance issues.
Furthermore, system model, application software model and communication model have different lifecycles: adding or removing a new application exchange in the former will (and should) not affect the latter (the communication model).
Now, a question could be raised: is there any reason to include some description of communication subsystem in the top level system engineering model? The answer may be ‘yes’ if the communication infrastructure is likely to impact the system architecture definition: for example by adding dedicated communication components, or influencing performance analysis (communication layers might consume some resources in the system), and also to specify to the communication engineering team the network nodes that have to be fed with communication capabilities, and more…
In this case, both application level and communication level “sub-models” will coexist in the same top level system engineering model, but the communication sub-model would be less detailed: for example, you could define only communication components (because of their need for resources), communication services functions and functional exchanges (if needed for specification), but no protocol-related component exchange and interface. You should not try to link both sub-models explicitly, with exchanges, for example, because of the reasons above.
One way to express, in the top level system (application) engineering model, ‘the relation between “the required communication services in the application model” with “the provided communication services by the communication model”’, could be (among others) to
- formalize these services as functions of the communication infrastructure,
- name the ‘paradigm’ (or ‘communication service’) properties on application level exchanges accordingly,
- and check, by means of model queries, that each application exchange is typed according to one existing service function name.
Note: this situation also applies to other fields beyond communication stacks engineering, such as cyber engineering for example.
For more tips like this, take a look at the very rich Arcadia Q&A webpage or the recent webinar by Jean-Luc on this subject.
BR
