Why some data flows between same low level functions have one single data object while some others have multiple

[mertaksac]

There are two specific data flows between F3.1.5.3 and F3.1.5.2 each carrying a single data object

• status
• occupancy

while another data flow between F3.1.5.2 and F3.1.5.4 carries them both

• status and occupancy

another example is this data flow between trip planning driver and F5.1.4.1 this one carries a few data objects

[burespe1]

These particular dataflows (status, occupancy) were not followed through by all functions and one was, by mistake - I guess, cut out.

Also this separation does not make sense, all necessary data shall be passed over to next function. Distinguishing between calculating occupancy / status is a micro-management that should not happen.

By our understanding MORE dataflows between 2 functions shall happen only when data passed over are fundamentally different, i.e. in C-ITS credentials (security) data and vehicle data (position, ...)

[bossomr]

One reason for multiple Data Flows between the same objects is the desire to make flexibility in the creation of ITS reference architectures from the FRAME Architecture easier. One of the ways to do this is to for each Data Flow to contain as few data objects as possible, or at least to try and separate out those data objects that could be left out for some ITS Services. I will try to illustrate what I mean with this example and must apologise if it appears childish:

Function 1 and Function 2 have three Data Flows between them, "fa_a", "fa_b" and "fa_c". Each contains a different data object that is sent from Function 1 to Function 2. An End User of FRAME is creating their own ITS reference architecture for a particular set of ITS Services. These ITS Services only need the data objects in "fa_a" and "fa_c", but not the data object in "fa_b". This means that in the ITS reference architecture that the End User is creating, they need only select "fa_a" and "fa_c", with "fa_b" being left out, i.e. not included.

An alternative is that Function 1 and Function 2 could have had one Data Flow between them ("fa_x") containing the three data objects that were included in "fa_a", "fa_b" and "fa_c". Now in the above example the End User now has to create a new Data Flow "fa_y" that links Function 1 to Function 2 and only contains the data objects that were included in "fa_a" and "fa_c". This is because "fa_x" cannot be used because it contains a data object that is not used.

This is a simple example and it may sound trivial, but the idea is to include flexibility for the End Users of FRAME and to make that flexibility easy to use. You could argue that it is OK to just have "fa_x" and forget that only two of its three data objects are used in a particular ITS reference architecture because the one left out is not needed by the ITS Services it will support. But that hides the fact that one of them is not used, which may be important in the Physical, Communications and other Views that are part of the ITS reference architecture the End User is creating for their ITS Services.

There may also be instances, such as the one highlighted by Mert, where in place two Data Flows are used and in another place the data objects they each contain are included in a single Data Flow. This is probably because they were created at different times and circumstances, and for the second Data Flow (with all the data objects) the idea of building in flexibility was temporarily forgotten - we are all only human after all. This is something that needs to be resolved either by creating an extra Data Flow, or combining two Data Flows into one, depending on the need for flexibility.

Building flexibility into the FRAME Functional View has been quite difficult, not least because what is flexibility for one End User is over complexity for another End User and you probably can never get it right for all End Users.

Looking to the future, I would advise the FRAME Maintainers to establish some clear and well documented guidelines about how much flexibility is to be included in the Functional View. Using the example above, what should be the guidance about including data objects in Data Flows? This and other similar guidelines will be vital if more than one person is going to maintain the Functional View.