How to model External Systems in an architecture subset?

[mertaksac]

How does the Other Related Systems terminator work?

When we do not want to include any Data Flow in a particular architecture subset, we delete those Data Flows. But this will also remove the interfaces of our system to external systems and isolate the system being developed. Instead of deleting them forever, shouldn't we replace them with the Data Flows to/from the Terminator, Other Related System?

Can this terminator be used to model external systems (out of the scope of FRAME)?

[mertaksac]

Peter Jesty wrote on 14 May:

I am not sure that I understand your problem.

(a) Surely part of the architecture/design of an ITS is a description of what it needs to talk to, the links are either there in order to do so, or they are not because they are not required. You might indicate to the developers/implementers that you don’t wish to have all the interfaces available from the start, but to include them in the architecture indicates that preparations can be made, if necessary, for their future inclusion.

(b) A consequence of this is that by including ‘everything just in case it might be wanted’ is that the detailed design will end up being much more complex, and thus expensive to implement, than is necessary – and you will soon not be very popular!

Other related Systems is the terminator that represents other instantiations of the FRAME Architecture only (by its definition). All other ‘external systems’ (out of the scope of FRAME) are represented by the other Terminators.

[bossomr]

Other Related Systems terminator: this terminator was introduced to enable the modelling of the data flows that sent to and received from another instance of parts of the FRAME functionality that exists in another geographic or jurisdictional area, e.g. country, region, district or city. The terminator contains the following sub-terminators, each of which is intended to replicate a particular part of the FRAME functionality:

• Emergency Management System – enables the transfer of data objects about incidents that have been notified to functionality in Functional Area 2 (Provide Safety and Emergency Facilities). So for example details about an accident that blocks a major road in one jurisdiction can be passed to adjacent jurisdiction because it may generate traffic queues that will be of interest to the second jurisdiction. • Environmental Traffic Management System – enables the transfer of data objects about environmental conditions that have been detected by functionality in Functional Area 3 (Manage Traffic). Thus if pollution is spreading from one area to another by the wind, the areas downwind can be notified in advance of its potential arrival. • Hazardous Goods Vehicle Route Monitoring – enables the transfer of data objects about the route that has been planned for a vehicle carrying hazardous goods that has been created by functionality in Functional Area 9 (Provide Support for Co-operative Systems). This is intended to enable a route to be planned by functionality in one geographic area to be passed to similar functionality in another geographic area. So for example if a route is planned by a system in Spain for a vehicle carrying hazardous goods to travel from Spain to Denmark, then the information about the route can be passed to systems in France, Belgium, The Netherlands and Germany. • Incident Traffic Management System – enables the transfer of data objects about incidents that have been detected and/or reported to functionality in Functional Area 3 (Manage Traffic). Thus details of an incident that affects the road network in one jurisdictional area can be passed to another (usually adjacent) jurisdictional area. It can also work between the systems that manage the urban (town/city) roads and the inter-urban (auto-route/motorway) roads and thus enable co-ordination of diversionary actions. • Inter-urban Traffic Management System – enables the transfer of data objects about the traffic management strategies that are being implemented in the inter-urban road network by functionality in Functional Area 3 (Manage Traffic). Again this can be from one jurisdiction to another, e.g. across a national boundary for a Euro-route (“E” numbered roads), and enables the functionality that receives the data flow to know about traffic management strategies in adjacent or related road networks. • Other Navigation Device – enables the transfer of data objects about trip plans that have been created by functionality in Functional Area 3 (Manage Traffic). Thus us is possible to transfer trip plans from one device to another, e.g. smart phone to car and visa versa. • Public Transport Management System – enables the transfer of data objects to/from functionality in Functional Area 4 Manage Public Transport Operations). There are three types of data transfer for this Sub-terminator, which are as follows:

• details about the PT fleet that is being managed by another instance of the functionality in High-level Function F4.5;
• plans for the maintenance of the PT fleet, because if one operator takes a significant proportion of its PT Vehicles out of service for maintenance, it could impact other PT operators;
• PT service schedules because the services being provided by one PT operator may have an impact on those being provided by other PT operator in the same road network. • Public Transport Stop – enables the transfer of data objects containing predicted PT service arrival times that have been determined by functionality in Functional Area 4 Manage Public Transport Operations) to the same functionality in another PT Stop. This enables the predicted service arrival times for a PT Service be transferred along its route as the PT Vehicle progresses from one PT Stop to the next.. • Traffic Signal Controller – enables the transfer of data objects about local vehicle priority requests that have been received by functionality in Functional Area 3 (Manage Traffic) to another instance of that functionality in an adjacent traffic signal controller. This enables local priority requests from a vehicle to be passed to each traffic signal controller it encounters along the route it is following. • Traffic Simulation System – enables the transfer of data objects that contain the results of a traffic simulation created by functionality in Functional Area 3 (Manage Traffic) to be sent to another instance of that functionality. So for example the results of a simulation performed for one Road Network Operator in one jurisdiction can be transferred to the simulation functionality being used by the Road Network Operator in another jurisdiction, perhaps in an adjacent or related road network. • Urban Traffic Management System – enables the transfer of data objects to/from functionality in Functional Area 3 (Manage Traffic). There are two types of data transfer for this Sub-terminator, which are as follows:
• traffic flow data for one road network being being transferred to functionality managing an adjacent or related road network so that the functionality in the second road network can be made aware of traffic conditions that may affect its own operations;
• traffic management strategies or special vehicle priority route that have been set up for one road network that are being sent to the functionality for an adjacent or related road network so that for the strategy, it can be taken into account when implementing traffic management strategies in the second road network. The transfer of the special vehicle priority route enables these routes to cross traffic management boundaries, i.e. from one road network to another.

The above must not be confused with the idea that Peter has described of putting part of the FRAME functionality into a terminator because for whatever reason, it is not going to be included in the sub-set ITS architecture that is being created. This idea of Peter's requires the creation of a new bespoke Terminator that represents that part of the FRAME functionality that is not being included in a sub-set Functional View. Such a Terminator will need new Terminator Data Flows and a new Low-level Function to send/receive them. The new Low-level Function will need to put the received data objects somewhere, possibly in an existing Data Store and extract the data objects to be sent from an existing Data Store, or be sent them by an existing Low-level Function. How the data is stored/retrieved will need the existing functionality to be modified to enable it to happen. The creation of this type of Terminator and its Data Flows as I have described is something that needs to be included in a User Guide. My suggestion is that we create a new User Guide 4, which contains what might be called “optional extras” or perhaps “advanced usage”, as there may be other similar things to be included for other parts of the FRAME meta-model and its stereotypes.

[PeterJesty]

Richard has misunderstood what I have said about the Other Related Systems – I did NOT intend it to say that it could be ANY sub-set of the FRAME Architecture (just those that have been previously defined – and found to be useful). Obviously another one could be defined if it was shown to be necessary (as can any part of the FRAME Architecture be extended)

[burespe1]

Richard, Peter,

is it so that if I want My System to be connected in the future to the other systems i.e. to FRAME "Public Transport Management System" I need to use a new terminator for that, with new data flows? I do not understand the reason, why not to use an already existing connection to "Other System"? I would understand the methodology if we want to connect to something completely new, but in a case of replication of existing functionality? Reuse of existing data flows is the least we can do.

Petr Bureš email: @.*** mob.: (+420) 777 131 603

po 17. 5. 2021 v 13:53 odesílatel bossomr @.***> napsal:

Other Related Systems terminator: this terminator was introduced to enable the modelling of the data flows that sent to and received from another instance of parts of the FRAME functionality that exists in another geographic or jurisdictional area, e.g. country, region, district or city. The terminator contains the following sub-terminators, each of which is intended to replicate a particular part of the FRAME functionality:

• Emergency Management System – enables the transfer of data objects about incidents that have been notified to functionality in Functional Area 2 (Provide Safety and Emergency Facilities). So for example details about an accident that blocks a major road in one jurisdiction can be passed to adjacent jurisdiction because it may generate traffic queues that will be of interest to the second jurisdiction. • Environmental Traffic Management System – enables the transfer of data objects about environmental conditions that have been detected by functionality in Functional Area 3 (Manage Traffic). Thus if pollution is spreading from one area to another by the wind, the areas downwind can be notified in advance of its potential arrival. • Hazardous Goods Vehicle Route Monitoring – enables the transfer of data objects about the route that has been planned for a vehicle carrying hazardous goods that has been created by functionality in Functional Area 9 (Provide Support for Co-operative Systems). This is intended to enable a route to be planned by functionality in one geographic area to be passed to similar functionality in another geographic area. So for example if a route is planned by a system in Spain for a vehicle carrying hazardous goods to travel from Spain to Denmark, then the information about the route can be passed to systems in France, Belgium, The Netherlands and Germany. • Incident Traffic Management System – enables the transfer of data objects about incidents that have been detected and/or reported to functionality in Functional Area 3 (Manage Traffic). Thus details of an incident that affects the road network in one jurisdictional area can be passed to another (usually adjacent) jurisdictional area. It can also work between the systems that manage the urban (town/city) roads and the inter-urban (auto-route/motorway) roads and thus enable co-ordination of diversionary actions. • Inter-urban Traffic Management System – enables the transfer of data objects about the traffic management strategies that are being implemented in the inter-urban road network by functionality in Functional Area 3 (Manage Traffic). Again this can be from one jurisdiction to another, e.g. across a national boundary for a Euro-route (“E” numbered roads), and enables the functionality that receives the data flow to know about traffic management strategies in adjacent or related road networks. • Other Navigation Device – enables the transfer of data objects about trip plans that have been created by functionality in Functional Area 3 (Manage Traffic). Thus us is possible to transfer trip plans from one device to another, e.g. smart phone to car and visa versa. • Public Transport Management System – enables the transfer of data objects to/from functionality in Functional Area 4 Manage Public Transport Operations). There are three types of data transfer for this Sub-terminator, which are as follows:

• details about the PT fleet that is being managed by another instance of the functionality in High-level Function F4.5;
• plans for the maintenance of the PT fleet, because if one operator takes a significant proportion of its PT Vehicles out of service for maintenance, it could impact other PT operators;
• PT service schedules because the services being provided by one PT operator may have an impact on those being provided by other PT operator in the same road network. • Public Transport Stop – enables the transfer of data objects containing predicted PT service arrival times that have been determined by functionality in Functional Area 4 Manage Public Transport Operations) to the same functionality in another PT Stop. This enables the predicted service arrival times for a PT Service be transferred along its route as the PT Vehicle progresses from one PT Stop to the next.. • Traffic Signal Controller – enables the transfer of data objects about local vehicle priority requests that have been received by functionality in Functional Area 3 (Manage Traffic) to another instance of that functionality in an adjacent traffic signal controller. This enables local priority requests from a vehicle to be passed to each traffic signal controller it encounters along the route it is following. • Traffic Simulation System – enables the transfer of data objects that contain the results of a traffic simulation created by functionality in Functional Area 3 (Manage Traffic) to be sent to another instance of that functionality. So for example the results of a simulation performed for one Road Network Operator in one jurisdiction can be transferred to the simulation functionality being used by the Road Network Operator in another jurisdiction, perhaps in an adjacent or related road network. • Urban Traffic Management System – enables the transfer of data objects to/from functionality in Functional Area 3 (Manage Traffic). There are two types of data transfer for this Sub-terminator, which are as follows:
• traffic flow data for one road network being being transferred to functionality managing an adjacent or related road network so that the functionality in the second road network can be made aware of traffic conditions that may affect its own operations;
• traffic management strategies or special vehicle priority route that have been set up for one road network that are being sent to the functionality for an adjacent or related road network so that for the strategy, it can be taken into account when implementing traffic management strategies in the second road network. The transfer of the special vehicle priority route enables these routes to cross traffic management boundaries, i.e. from one road network to another.

The above must not be confused with the idea that Peter has described of putting part of the FRAME functionality into a terminator because for whatever reason, it is not going to be included in the sub-set ITS architecture that is being created. This idea of Peter's requires the creation of a new bespoke Terminator that represents that part of the FRAME functionality that is not being included in a sub-set Functional View. Such a Terminator will need new Terminator Data Flows and a new Low-level Function to send/receive them. The new Low-level Function will need to put the received data objects somewhere, possibly in an existing Data Store and extract the data objects to be sent from an existing Data Store, or be sent them by an existing Low-level Function. How the data is stored/retrieved will need the existing functionality to be modified to enable it to happen. The creation of this type of Terminator and its Data Flows as I have described is something that needs to be included in a User Guide. My suggestion is that we create a new User Guide 4, which contains what might be called “optional extras” or perhaps “advanced usage”, as there may be other similar things to be included for other parts of the FRAME meta-model and its stereotypes.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/FRAME-NEXT/FRAME/issues/59#issuecomment-842262340, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKJFJTTJ5444TYRV3MQBJFTTOD7SVANCNFSM442MKIMQ .