System Wide Information Management (SWIM) is the cornerstone of the future air traffic management system. While the underlying concept of SWIM is not overly complicated, it does require a shift in thinking something that tends to result in different interpretations, some closer to the real thing than others. In the following we present an understanding of SWIM that we think is a basically correct reflection of the main features of the idea. This is being done in the hope that many who are interested in SWIM will be able to grasp some details that were hitherto less well understood. When SWIM is actually implemented, some elements might have different names but the elements will be more all less the same. What follows is not a SWIM architecture in the strict sense of the word. It is an illustration of the concept and its elements.
I am sure many of our readers will have questions or concerns, some may even find errors in this write up. Use the comment option or send is mail.
Let’s work on getting a common understanding of SWIM!
The big picture
The following diagram shows a simple, high level depiction of the main conceptual elements of SWIM.
The blue Institutional background signals the fact that SWIM is as much a set of roles, rules and responsibilities that apply to SWIM itself and to its users, as it is a technical facility. It also shows that the users of SWIM, like for example ANSPs and airspace users, are in part under the SWIM institutional background as users and providers of information. Clearly, SWIM is external to ATM, however it supports ATM as the enabler of the end-user applications implemented in the various user systems.
SWIM in detail
The following diagram represents the same SWIM concept as the one before, however, with more detail on the information providers and users as well as the management and provision of SWIM specific services.
In the following, a detailed explanation of the different elements shown in this more detailed depiction is given.
SWIM Institutional framework (SIF)
The Institutional Framework encompasses all enabling activities required to create the technical and commercial regulatory environment in which cost efficient, safe and secure information sharing for ATM purposes can be practiced. This includes also the necessary standardisation and the rules for licensing on the European regional level. This framework serves also as the high level regulatory interface to the rest of the world.
It is in this framework that necessary amendments to ICAO and European provisions (e.g. Annex 11, 3, 15, 10, Doc. 4444, 7030 etc.) on which SWIM has an impact are initiated and carried to approval. This includes extending the scope of aeronautical information and integrating MET information in the extended scope. The Common ATM Information Model is also developed under the stewardship of the SIF.
Who “owns” SWIM?
The concept of SWIM recognizes the ownership of the data managed in it, but there is no “owner” of SWIM itself. It is also against the SWIM principles to allow any particular organisation or group of organisations to become a monopoly for providing any service on any level in the SWIM environment. Service provision on all levels in SWIM is open to competing providers as long as they meet the published requirements (and are duly licensed if applicable).
It is also against the SWIM concept to prescribe to any ATM partner which provider to use for any service on any level.
SWIM_Net (by licensed providers)
SWIM_Net is the underlying network infrastructure supporting system wide information management in all its network aspects. It is NOT a dedicated network but an industry standard networking capability without proprietary solutions, run by cost-efficient providers, meeting the requirements posed by ATM and appropriate to the different kinds of data being exchanged.
It is important to note that different ATM data have different needs and SWIM_Net enables this differentiated service. This reduces overall costs on the one hand and enables the early implementation of services and applications that do not pose the highest requirements which will only be possible to satisfy in later phases of SWIM implementation.
Common services (by licensed providers)
Common services encompass those network services that are required for the data services on the network (directory, discovery, security, etc.). These common services also ensure the interoperability with other SWIM-type environments (e.g. USA). These services are provided by providers licensed according to the applicable rules defined under the SIF.
EUR SWIM Management
EUR SWIM Management is the European entity (i.e. not under an ANSP or other user) charged with the daily supervision of all aspects of the SWIM operation. This entity is responsible for the evaluation of license requests, issuing and withdrawing licenses, dealing with details of the security arrangements, quality issues, etc. It operates in accordance with the applicable rules defined under the SIF. EUR SWIM Management could possibly take the form of a not-for-profit consortium looking after the interests of all users of the system.
Traditional users and providers of information (ATM, FOC, Airport)
ATM provider (includes also ATFCM), FOC and Airport are instances of traditional ATM users and providers of information. Using their systems, they publish their information into SWIM_Net and obtain necessary information from SWIM_Net in a number of different ways (subscription, direct query, etc.).
Local SWIM Connectivity Service (C_S)
The Local SWIM Connectivity Service represents those changes required in local systems (including aircraft systems) that enable them to exchange data (publish, receive) via SWIM_Net. Local SWIM Service is NOT a set of people or local supervisors, it is purely a system provision. There is no need to supervise any aspect of SWIM locally!
End-user common applications
End user common applications are NOT in fact part of SWIM as such. They only make use of the information sharing capability. They are called common applications because they fulfil certain functions common to several ATM partners.
Note that these applications are specified in accordance with a performance based approach to their design. This means that they request data of the required quality without specifying the source. This ensures early benefits since data of the required quality from ANY source can be used (e.g. if trajectory data is available from the FOC only, it is accepted the same way as that from the FMS via air ground data link, if the quality is otherwise identical. This is an example of the early benefits of SWIM based information sharing that can bridge the gap until air/ground data link is more widely available.
An example of a common application is the arrival manager. While the core algorithm may differ from location to location, the data it needs and the data it outputs is subject to all the information sharing rules.
Another example is the Network Operations Planner (NOPLA) or trajectory/flight data submission applications that replace the ICAO new flight plan for flight in the SESAR area.
End-user specific applications
End user specific applications are NOT in fact part of SWIM as such. Different end users may have different and even unique needs in respect of their particular operation. End user specific applications are built to cater for such needs in as much as they are able to use information available in SWIM_Net and can also be charged for chargeable services/information. The output of such an application is not necessarily shared. If it is, it is subject to all the information sharing rules.
An example of such an application is for example a local trajectory modelling tool, which may or may not feed a trajectory submission tool where this latter is an end user common application.
These applications are also performance based, as described above.
The aircraft
The aircraft are data users and providers, with applications of similar characteristics to all other users/providers. It should be noted that MET observations made by an aircraft will be published into SWIM_Net like any other information and there is no need for any special interface between aircraft/FOC and the MET providers.
On the SWIM figure, a direct link is shown between the aircraft and the FOC. This signifies the possible desire of airspace users to retain such a direct link for their own purposes. This is not contrary to the SWIM principles as long as the SWIM defined rules, roles and responsibilities assigned to the FOC and the aircraft are duly observed.
Connection between an aircraft and SWIM_Net can take several forms and this is also specified on a performance basis. Hence a GA aircraft will be required to possess a link appropriate for their needs only.
Note that air/air information exchange is not shown separately here. While such exchange will happen directly between the aircraft concerned, information of ATM relevance will be published into SWIM_Net by the aircraft concerned and hence from a logical perspective, there is no difference between this kind of data exchange and that via SWIM¬_Net.
Individual pilots, drivers, etc.
These entities are typically people or ground vehicles accessing information via mobile devices. Examples would be a private pilot submitting a trajectory and other flight data from a PDA or the operator of a de-icing truck consulting the pre-departure sequence on mobile device in the truck. Applications on such devices will be optimised for the more limited capability but otherwise the performance based approach applies.
It is also envisaged that under this category data may be sold/made available to enthusiasts, researchers, etc., eventually with a time lapse to protect real time operations. The eventually ensuing revenue can be used for various agreed purposes.
Licensed information providers (AIS, MET, flight data, etc.)
Licensed information providers are the entities duly authorised under the provisions of the SIF, as shown by the license issued by the EUR SWIM management, to provide essential data into SWIM_Net. They are responsible for the quality of the information they provide.
Such providers include State organisations (formerly known as AIS) fulfilling an obligation of the State to provide aeronautical information, MET information providers, value added providers like Jeppesen to-day, etc. Such an entity will be charged with the reception of aeronautical and flight data from non-SESAR areas as well as the provision of legacy information to non-SESAR areas. Note that “entity” here does not mean a single, centralised entity per-se.
Trusted user/provider
Trusted users and providers are entities who are not appropriate for licensing or are not required to be licensed as they will only ever use data from SWIM_Net, never supplying data into it. They need to be registered only to ensure charging, if applicable.
A trusted user would be the FAA for instance, with privileges to use and submit information. An airport taxi company wishing to purchase arrival information would be an example of the second category.
Licensed Surveillance Service Provider
In the future, surveillance may very well be outsourced for reasons of cost efficiency. Such providers will have to be properly licensed of course. However, on this illustration the important element is the direct connection between the surveillance service provider and the ATM provider. This is in recognition of the fact that initially SWIM_Net may not be suitable for handling all the surveillance information available in Europe to-day. With the optimisation of the surveillance infrastructure, however, SWIM based operation should be possible.
It is important to note that abbreviated/limited surveillance information should nevertheless be provided into SWIM_Net right from the start to support applications requiring it.
High-speed network connections
Red arrows represent high speed network connections into the network, with sufficient bandwidth to cater for the needs of the applications being used.
Link between aircraft and SWIM_Net
A pink arrow represents the connection between an aircraft and SWIM_Net. This being a performance based system, the link to be used is specified from a SWIM point of view in terms of performance only.
The grey arrow is shown only as a reminder that airspace users may retain legacy links for their own use.
Security
The SWIM security concept is based on the fact that not all data and the information that can be deduced from it is equally sensitive and hence the level of security to be provided must be carefully calibrated to the actual need and not some perceived “importance” to certain interest groups.
This approach ensures that costs and system complications are kept low, information availability and accessibility is not adversely impacted by security overkills while the legitimate protection needs are fully catered for.
A system similar to that developed by the US National Security Agency called Multiple Independent Levels of Security could be envisaged. MILS specifies how information should be partitioned and protected while running on the same server. Levels are from 1 to 7, where 7 is the most secure.
1 comment