| Navigation | |
Development of an AIS Transmit Architecture
This paper describes the ASM transmit architecture and the testing that has been done to date to validate this architecture |
 |
|
 |
|
|
The Automatic Identification System (AIS) is an autonomous and continuous broadcast system that exchanges maritime safety/security information between participating vessels and shore stations. In addition to providing a means for maritime administrations to effectively track the movement of vessels in coastal and inland waters, AIS can be a means to transmit information to ships in port or underway that contributes to safety-of-navigation and protection of the environment. This includes meteorological and hydrographic data, carriage of dangerous cargos, safety and security zones, status of locks and Aids to Navigation (AtoNs), and other port/waterway safety information.
In the United States, it is intended that this additional information be transmitted from shore-side AIS base stations in a binary message format as part of an overall e-Navigation strategy. The Committee on the Marine Transportation System (CMTS) e-Navigation Strategic Action Plan (“e-Navigation Strategic Action Plan” 2012) quotes the International Maritime Organization (IMO) definition of e-Navigation as:
“e-Navigation is the harmonised collection, integration, exchange, presentation and analysis of maritime information onboard and ashore by electronic means to enhance berth to berth navigation and related services, for safety and security at sea and protection of the marine environment”
AIS capabilities are recognized as critical parts of the US e-Navigation strategy in the CMTS e-Navigation Strategic Action plan. To implement these capabilities, the United States Coast Guard (USCG) Research and Development Center (RDC) has been working on an AIS Transmit Project since 2007 to research what additional information is required by AIS users, to recommend how the information should be transmitted, and to test transmission of this information at test bed sites. In order to transmit the information, it must be formatted into standard messages, called Application-Specific Messages (ASM). As part of the AIS Transmit Project, several new ASMs have been defined and prototype methods have been developed for message creation, routing, queuing, transmission and monitoring.
In general, ASMs are either created by a person (such as Vessel Traffic Service (VTS) operators, lock operators, or Sector Command Center (SCCs) watchstanders), or retrieved from an information data source (such as the National Oceanographic and Atmospheric Administration’s (NOAA) Physical Oceanographic Real Time System (PORTS) or United States Army Corps of Engineers (USACE) lock operations databases). This information is then formatted into ASMs based upon accepted standards. Once formatted, messages are prioritized, geographically identified, and queued for transmission. As part of the queuing process, the AIS Very High Frequency (VHF) Data Link (VDL) must be monitored and feedback provided to the queuing process to adjust message output. Once formatted, the ASMs are sent to the AIS base station or AIS AtoN unit for transmission.
The identification of the processes led to the development of a prototype AIS Transmit architecture which includes the use of an ASM Manager and an AIS network controller or “AIS router” that is used to route data between the Physical Shore Stations (PSSs)/AIS Base Stations (BSs) and the various clients (database storage, Geographic Information System (GIS) displays, etc.).
In order to have a cohesive, flexible and robust AIS transmit system that meets all users’ requirements, an AIS transmit architecture needs to be fully defined. This paper proposes such an architecture and describes the various components of that architecture including an ASM Manager to implement the queuing and prioritization algorithms. Results of base station testing and how the results impact the transmit architecture are also presented. Additionally, the paper presents a mapping of AIS transmit message types onto the recommended transmit methodology based upon the results of RDC testing. Finally, the paper briefly presents the various US test beds that have been used to develop these processes and architetectures.
AIS Transmit Architecture
RDC has developed a proposed AIS architecture that is in alignment with International Standards. This is described in the sections below after first detailing the International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA) and IMO reference architecture for e-Navigation.
IALA Reference Architecture
The 1998 IMO Performance Standards for AIS (“Recommendation on Performance Standards for an Universal Shipborne Automatic Identification System (AIS)” 1998) state:
1.2 The AIS should improve the safety of navigation by assisting in the efficient navigation of ships, protection of the environment, and operation of Vessel Traffic Services (VTS), by satisfying the following functional requirements:
1. in a ship-to-ship mode for collision avoidance;
2. as a means for littoral States to obtain information about a ship and its cargo; and
3. as a VTS tool, i.e. ship-toshore (traffic management)
This was expanded upon by the International Telecommunication Union Radiocommunications Sector (ITU-R) in the preamble to Recommendation M.1371 (“ITU-R M.1371-4” 2010)
The ITU Radiocommunication Assembly considering (…)
b) that the use of a universal shipborne AIS allows efficient exchange of navigational data between ships and between ships and shore stations, thereby improving safety of navigation;
d) that although this system is intended to be used primarily for surveillance and safety of navigation purposes in ship to ship use, ship reporting and vessel traffic services (VTS) applications, it may also be used for other maritime safety related communications, provided that the primary functions are not impaired;
f) that this system is capable of expansion to accommodate future expansion in the number of users and diversification of applications, including vessels which are not subject to IMO AIS carriage requirements, aids to navigation and search and rescue;
And further noted in IALA Recommendation A-123, on “The Provision of Shore Based Automatic Identification System (AIS),”(“IALA A-123 Ed 2” 2007) which states “National Members and other appropriate authorities should therefore consider the provision of an AIS shore infrastructure so that the full benefit of the system can be realized in terms of navigation safety and protection of the environment.”
IALA Recommendation A-124, “On The AIS Service” (“IALA A-124 Ed 2.1” 2012) provides a service model for the AIS-based shore service component of e-Navigation. The details are described in the various Appendices to A-124. Figure 1 shows the layered structure for this service. The three main functional layers are the Service Management Layer (AIS Service Management Layer or AIS-SM), the Logical Layer (AIS Logical Shore Station or AIS-LSS), and the Physical Layer (AIS Physical Shore Stations or AIS-PSS). Each layer is comprised of “the service component itself, which provides the required functionality in terms of AIS specific data processing; the supporting components and resources, which are exclusively used by the AIS Service, such as computers and local networking devices, i.e. the so called service-owned infrastructure; and the Human Machine Interfaces (HMI) to allow for (remote) access to Technical Operation Personnel.”
The AIS-Service Manager (SM) (described in more detail in Appendix 11 (“IALA A-124 Appendix 9-10-11” 2012) provides for the management of the entire AIS service. This includes configuration and monitoring of all components and an HMI for technical personnel to do the configuration and monitoring.
The AIS-Logical Shore Station (LSS) (described in more detail in Appendix 9 (“IALA A-124 Appendix 9-10- 11” 2012) acts as a software router for AIS data going to and from the clients and the AIS PSS Controlling Units (AIS-PCU). It is responsible for the management of client and AIS-PSS connections, filtering of data on either or both connections, and data logging.
The AIS-Physical Shore Station (PSS) (described in more detail in Appendix 10 (“IALA A-124 Appendix 9-10-11” 2012) “is an abstract concept that encompasses multiple real physical elements of a shore-based AIS Service.” The major components of an AIS-PSS are: an AISPCU that is in charge of controlling one or more AIS fixed stations; at least one AIS fixed station (base station, limited base station, AtoN, or repeater station) that provides the interface to the VDL; and an agent of the AIS-SM to allow for configuration and monitoring of the AIS-PCU and AIS fixed station(s). In some cases all of this functionality can be rolled into one physical component.
Proposed Transmit Architecture
One of the major outcomes of the test beds was the identification and quantification of the processes needed in order to create and transmit ASMs: Message Creation, Routing, Transmission, and VDL Monitoring. This is shown in Figure 2. Message creation could be accomplished automatically from a database (of met/ hydro, weather or lock information for example) or user-created. If the message created is from a database, then software is needed to fetch the data and put into the correct format (AIS ASM embedded into a National Maritime Electronic Association (NMEA) sentence). If usercreated, then software tools (preferably GUI-based) are needed to put the desired information into the ASM. Message routing involves both the queue process and rules-based prioritization. This is not available off-the-shelf currently so additional software (ASM Manager) is needed to accomplish this. Message transmission involves routing the message to the correct transmitter (AIS base station, AtoN, or perhaps limited base station) according to the area the content of the message applies to or in order to reach the intended addressee (auto or user-specified). Monitoring is VDL loading monitoring to ensure that the number of messages desired to be transmitted do not overload the VDL.
The identification of these processes led to the development of a prototype AIS Transmit architecture, which includes the use of an ASM Manager to perform the processes that are not available in off-theshelf applications and equipment; and an AIS network controller or “AIS router” that routes data between the Physical Shore Stations (PSSs)/AIS Base Stations (BSs) and the various clients (database storage, Geographic Information System (GIS) displays, etc.). This proposed transmit architecture for AIS (shown in Figure 3) is based on the IALA model described above. Each of the major components of the proposed architecture is described in the following sub-sections.
Information Routing Notes (see letters in Figure 3, the AIS message types are explained in Table 1, the ASM Function Identification (fi) is explained in Table 2, the Designated Area Code (DAC) used in the ASM is 367):
A. The AIS Service Manager (AISSM) is used to program the AIS PSS Controlling Unit (AIS-PCU); i.e. base stations, for AIS Messages: 4, 17 (opt), 20, 23 (opt) and 24 (opt). The AIS-PCU generates AIS Messages 7/13 automatically upon receipt of AIS Message 6/12. The AIS-SM also programs AIS AtoNs for AIS Message 21 (opt) or AIS-PCU for AIS Message 21 (Opt. Synthetic or Virtual AtoN).
B. Client Processes collect information from Users and generate NMEA sentences to initiate (telecommands) AIS Messages: 10, 15, 16, 22, and 23(opt). Client Process could be part of a GUI. Various clients could also be used for messages 25/26, and 21.
C. ASM Manager(s) receive messages from AIS router and from NOAA PORTS, feeds managed stream of NMEA Sentences to AIS-PCU to generate AIS Messages: 6, 8, 12, 14, and 25/26.
D. User creates ASM in a client process or GUI, these are embedded in NMEA sentences and sent to ASM Manager (DAC/FIs: 367/22, 367/35, 367/29, etc.)
E. Database processes retrieve data, format into ASMs embedded in NMEA sentences and forward to AIS Router for transmission (DAC/ FIs: 367/22, 367/35, 367/29)
F. Text messages (should be limited to safety-related information and not used often) could be created by various client processes or by a GUI
AIS Router
The primary component that implements the AIS-LSS is an “AIS Router;” so called, because it is responsible for routing the AIS data between the AIS service clients and the AIS-PSS. A market survey conducted by RDC identified four major commercial vendors that supply AIS Routers as part of their AIS shoreside network software (Johnson and Gonin 2013). All of the software packages allow for multiple client connections (examples shown across the top of the box in Figure 3 above); each client connection typically has username and password authentication although this is not required in all cases. Each client can be configured for different levels of access and data stream filtering (both send and receive). The software also manages multiple connections to AIS data streams; either from other AIS Routers (in a regional or national hierarchy) or from AIS-PSSs. All of the software packages implement data stream filtering on these connections as well. Different vendors offer different features, but in general they all fully implement the required capabilities of an AIS-LSS.
The other major component of the AIS-LSS is the data logger. This is implemented by all of the vendors in a separate software component that works in conjunction with the AIS Router. Typically this is done using an Oracle or Structured Query Language (SQL) database, but in some cases, flat files are used as well.
AIS Router Test Results
RDC conducted testing on the four AIS routers identified in the market survey (Kongsberg C-Scope, Gatehouse AIS, Transas AIS Network, and CNS DataSwitch). Copies of each of software were obtained and installed on a test bed at RDC, running the software on the same computers to allow relative performance comparisons. The systems were run through a series of tests that can be characterized into two categories: basic and performance. The tests were designed to assess the performance of the systems in regards to routing functionality and the criteria that the project sponsor thought most important: raw throughput speed and maximum number of clients possible. Database storage, analytics, and display capabilities were not evaluated, although all of the systems have these capabilities.
Complete details on the testing performed can be found in (Johnson and Gonin 2013) but the results are summarized here. From a performance standpoint, any of the four commercial systems would be suitable for the AIS router. The overall aggregate traffic load in the United States in 2013 was about 600 messages per second. The systems tested could support from 3,900 to 17,000; all well above the current maximum. The numbers of clients supportable ranged from 35 to 250. CNS supported the most; however, all of the other systems have scalable client modules that would allow for expansion to almost an unlimited number of clients by adding client modules (the reported client counts are for a single instance of the client server modules). How many clients are required, has not been determined.
The study only assessed performance for a few specific criteria; all of the commercial software has much more functionality than that assessed. Much of this functionality would be important for the overall system, and some of the functionality would impact the performance results. For example, setting different filters for each client increases the Central Processing Unit (CPU) loading; especially if geographic filters are used. One of the lessons learned from the study was that the system settings can be critical to performance. Another was that an overall architecture for an AIS network that supports full two-way communications needs to be developed. Part of this architecture design needs to include tradeoffs on data flow and data storage at the local, regional, and national levels. For example, most of the vendors in this study would recommend downsampling the data as it is aggregated at the regional and then national levels and only store the full time-rate data at the local (or at most regional) levels. Additionally, in order to specify the hardware and software, the maximum number of clients required to be supported at each connection level (local, regional, national) needs to be determined. This nationwide architecture is not reflected in Figure 3.
ASM Manager
The ASM Manager is software that adds additional necessary functionality to the “AIS router.” This is not available off-the-shelf currently, so software was developed to layer this functionality on top of an AIS router. This program was designed to shield the message creator from the details of the base station locations and manage ASM transmissions by performing the following functions:
1. Ensures messages are valid before transmission.
2. Ensures that no more than the user-specified number of slots is used for transmission in each minute in order to minimize the transmit loading on the VDL.
3. Allows for user-specified priorities along with prioritization based upon message type and content.
4. Determines if a message should be transmitted from a given transmitter based upon location.
5. Ensures messages are transmitted.
6. Keeps messages in queue until acknowledgement is received from the BS.
7. Allows for acknowledgement to be routed back to user.
8. Manages the repetition of messages that need to be retransmitted on a periodic basis.
ASM Manager accepts Broadcast Binary Message (BBM) and Addressed Binary Message (ABM) sentences containing environmental messages, waterways management messages, text messages and geographic notices from various data feeds such as the DataSwitch. ASM Manager stores those messages in its internal queue. At periodic intervals (from 4 – 60 seconds), ASM Manager forwards the ASMs on to the Base Station for transmission. ASM Manager prioritizes and limits the maximum number of messages that are output each interval based upon its configuration parameters (maximum number of messages in a report and maximum number of reports per interval).
ASM Manager has a built-in mechanism for detecting and purging expired messages. All messages receive a timestamp upon delivery to ASM Manager. In addition, ASM Manager parses the date and time of incoming environmental and geographic notice messages and uses that time for detecting message expiration. For other message types, time of reception is used for detecting expired messages. The expiration period for geographic notice messages is decoded from the binary message. For other message types the expiration period is specified in the configuration file. Expired messages are purged from the queue prior to sending data to the transmitter.
ASM Manager decodes station ID, data type and sub-type for received messages. If a message with the same station ID and data type and sub-type and same DAC (either 366 or 367) and same fi(either 1, 22, 29, 33, or 35) is already in the message queue, it is replaced with the updated information. Message priority, number of times the message was delayed, number of times the message failed to transmit and the next send time are carried over from the obsolete message to the updated message.
ASM Manager sorts messages by userspecified priority and limits the number of messages that are transmitted every minute (set via configuration parameters), so as not to overload the VDL. The message base priority can vary from 1 to 10, with 10 being the highest priority. Messages that fail to transmit or are delayed (due to too many messages in the queue), have their priority boosted by 1 for each time the message is delayed or fails transmit (while its base priority remains the same). If a message is transmitted successfully, its fail-to-transmit and delay counters are reset, so its priority returns to the base priority. Since the AIS VDL is organized into 1-minute frames, ASM Manager nominally sends out messages once a minute; however this can be adjusted to an interval of 4 to 60 seconds to meet operational needs.
ASM Manager monitors the AIS base station feedback for ABK acknowledgements that indicate success or failure of message transmission. In case a message is not acknowledged, that message gets put back into the transmit queue and its failed transmit counter gets incremented. Messages that fail to transmit are scheduled for retransmit in the next transmit cycle.
ASM Manager can accept metadata along with the ABM/BBM sentence (repeat rate, priority, and area of transmission) in PRDC,ATH sentences. ASM Manager can filter out messages by area of transmit specified in PRDC sentence if filtering is turned on. PRDC and ABM/ BBM sentences are expected to adhere to the following sequence: [optional PRDC][BBM 1 of x]…[BBM x of x]. ASM Manager checks for various error conditions and in case of errors, it generates email alerts about the outages. To reduce the number of emails, a single email alert notice is generated in a 24-hour period that contain all errors and alerts that occurred since the last email was generated.
ASM Manager provides configurable monitoring and logging capabilities and an interactive user interface. The user interface allows turning on and off display of the message queue (before and after each transmit), display of message information, deleting messages from the queue, and stopping program operation.
AIS-PSS Layer
Although the IALA model for the AISPSS layer includes an additional AIS-PCU sub-layer, the USCG R&D installations do not use this. Any functionality of the AIS-PCU layer is handled by the AIS Fixed Stations. In the case of the Tampa test bed this is an L-3 Protec base station. For the Columbia River, this is two SAAB R-40 base stations. Louisville is currently a SAAB R-40 base station but this is being transitioned to an L-3 Protec. The Stellwagen Bank test bed uses an L-3 AtoN transmitter. The USACE LOMA system also uses L-3 AtoN transceivers. Configuration of these transceivers is accomplished either through the AIS Service Manager or directly through the AIS AtoN transceiver.
Mapping AIS Transmit Messages to Architecture
AIS has been very successful in providing VTS and other shore facilities with vessel position and identification information, but in addition AIS can be a very effective tool for communication between shore stations and vessels. AIS accomplishes this by utilizing the capability of pre-formatted standard messages and AIS binary messages or application-specific messages (ASM). For clarification purposes, transmit capability is defined to include both broadcast and addressed AIS messages. The current AIS specification, (“ITU-R M.1371-4” 2010) defines 27 different AIS messages shown in Table 1. Some of these message types can be grouped into categories applicable to AIS transmit: message types 4, 17, 20, and 24 are base station messages; message types 10, 11, 15, 16, 20, 22, and 23 can be considered telecommands that can be used by a VTS for channel management; message types 12, 13, and 14 can be used for safety- related text messages; and message types 6, 7, 8, 21, 25, and 26 are binary messages that can be used for information transfer. Table 2 provides the valid function identifiers for DAC 366/367; these are the messages currently used in the United States.
Message Transmission Options
There are three ways to have a base station transmit an AIS message; each method has pros and cons, and some AIS messages are better suited to certain methods. Each of the methods and the recommended AIS messages are described in the following subsections. The methods
Method 1: Base Station Programming
A typical base station (such as the L-3 Protec) can be programmed to generate some AIS messages automatically. The AIS-SM layer does the programming – whether this is third-party software such as CNS’s Maestro or the base station vendor’s software (e.g., L-3 Base Station GUI). The messages are configured and assigned to a repetitive transmit schedule. Slots can also be reserved for these messages. There are some AIS messages that would be difficult to create and/or manage by one of the other two transmit methods and so should be sent using this method. The messages that fall into this category are: AIS messages 4, 17, 20, 215, 228, and 24.
Method 2: NMEA Sentence Programming
A base station supporting NMEA 4.0 can be configured to transmit most AIS messages using various NMEA sentences. In this case a client application could create the appropriate NMEA sentences and send them through the network to the base station. The base station uses the information in the sentences to create and transmit the AIS messages. Most messages that a base station can transmit can be configured and sent in this manner. The advantage of this method vs. Base Station Programming is that a client application (not just the AIS-SM) could request the transmission of the AIS message. The advantage of this method vs. Directly Created AIS Messages is that this method does not require the client to know anything about the VDL or the current slot map; the base station handles that when it creates the AIS messages from the information in the NMEA sentences. The messages that are recommended to use this method are: AIS messages 6, 8, 12, 14, 15, 163, 216, 229, 25, and 26.
Method 3: Directly Created AIS Message
A base station can be forced to transmit any AIS message by embedding the AIS message in a VDM sentence and sending that to the base station. This allows tremendous flexibility; however, it puts the entire burden of the AIS message creation and VDL management onto the client. The L-3 Protec base station and L-3 AIS AtoN will generate a TFR sentence that reports the status of the VDM message delivered to the transceiver (e.g., whether it was successfully scheduled for transmission) back to the client which is very helpful; however, this is not required by the NMEA standard and thus cannot be expected with all AIS transceivers. There are several AIS messages that would be very difficult to create and manage using this method, and thus are not recommended for this transmission method (AIS 4, 17 and 20 for example). The messages that are recommended to use this method are: AIS messages 61, 82, 164, 217, and 2410.
US Test Beds
The AIS Transmit project’s primary test bed is located in Tampa, fl. The project also expanded to include demonstrations and trials in the Stellwagen Bank, MA, Louisville, KY and the Columbia River, OR. This work has been reported on previously in (Gonin and Johnson 2009; Johnson 2009; Johnson, Wiggins, and Gonin 2012; Burns et al. 2011; Gonin et al. 2009) but is summarized in the following sub-sections.
Tampa Bay, fl
The Tampa VTS test bed was installed and commenced operation in September 2008. The Tampa Bay Pilots and Tampa VTS (operated by the USCG and Tampa Port Authority) have been very supportive partners. The test bed personnel are able to create and deliver binary messages, which mariners can use aboard ship. This information provides the pilots with better situational awareness of met/hydro conditions in the port area and has been used for decision support (go/no-go decisions). The primary source of data has been PORTS; this data is transmitted over the VDL using the Environmental ASM. The ASMs are sent to the AIS base station in Largo, flthat is shared with the VTS operations system (Norcontrol™ software by Kongsberg). The Nationwide AIS (NAIS) receiver at Palmetto is used as the monitor site. Figure 4 shows the locations of the base station (upper left) and the receiver (lower right) relative to Tampa Bay. The Tampa Pilots use a text display of the data on their Portable Pilot Units (PPUs) (similar to Figure 5). The Tampa test bed has been the primary test site to evaluate processes and performance for future implementation at all Coast Guard VTS sites. The testing done in Tampa has enabled an understanding of the transmit processes and driven the development of the proposed transmit architecture.
Stellwagen Bank
The Stellwagen Bank demonstration has been a joint effort between RDC and NOAA Stellwagen Bank National Marine Sanctuary (NMS) (with University of New Hampshire (UNH) and Cornell University support). The location of this test bed is shown in Figure 6. The goal of this effort is to broadcast via AIS an indication of the presence or absence of right whales in the vicinity of the 10 acoustic monitoring buoys so that ships can slow down if there are whales in the area. The AIS broadcast portion of the demonstration started in September 2008. The user equipment side (NMS/UNH responsibility) started operation in earnest with an iPad application (WhaleAlert) in 2012. NOAA NMS is the overall lead for this effort. Cornell is responsible for the operation of the acoustic buoys; they receive the acoustic signature data from the buoys via an Iridium satellite link and process it to determine if right whales are present or not. This information goes into their database where it can be accessed and viewed over the Internet. UNH provides software support and wrote the code that retrieves the right whale data from Cornell’s database and provides Geographic Notice ASMs to the ASM Manager. An AIS AtoN unit is used as the transmitter (this was substituted for the original base station in Jan 2011). The NAIS receivers in the Boston area are used as monitor sites.
Columbia River
The Columbia River Demonstration started as a joint effort between the RDC, the Columbia River Pilots (COLRIP), and the US Department of Transportation, Volpe Center; as of Aug 2010, the Volpe Center assumed responsibility for the AIS transmit operations in the Columbia River as part of their contracted support to the COLRIP. There are two AIS base stations (Green Mountain and Meglar Mountain) which are operated in repeater mode so that all traffic received by each base station is retransmitted. COLRIP and Volpe are responsible for monitoring system performance and VDL loading using data feeds from the two transmitter sites. RDC conducts monitoring on an ad hoc basis using the NAIS receiver at Cape Disappointment. A chart showing relative positions of the transmitters/receiver is shown in Figure 7. The Columbia River Pilots actively use the environmental data as part of their operations. They use Volpesupplied TV32 software as their Personal Pilot Units and like the geographically tied text display. The test bed with two transmitters in a repeater mode provided some valuable experience in repeater operation and VDL impacts. This is documented in (Johnson 2010).
Louisville, KY
A test bed was established in Louisville in 2011 in order to develop and test new sources of environmental data for transmission such as river current sensors and river gauge sensors and to test the usage of the Waterways Management (WM) ASMs and assess their usefulness. The transmitter is an AIS base station located in Louisville, KY that is used by the VTS. This test bed was also the first to be set up using the new transmit architecture and processes. Although this provided a good test bed for developing the new architecture software, only some of the phase I test goals were met. The biggest hold-up was the lack of fully functioning user software. This limited RDC’s ability to collect feedback from the mariners on the usefulness of the messages. In order to complete the assessment processes, the decision was made to conduct a Phase II test at Louisville.
The primary goals of the second phase are to fully test the Waterways Management ASM and to assess usefulness from the mariner’s point of view. To enable this RDC has worked with two software manufacturers, CEACT and RosePoint to get their software updated to support the decoding and display of the ASMs. Phase II commenced operation on 1 July 2013. A survey of mariners involved was conducted on 14-15 August 2013. Since none of the stakeholders had used the new ECS software with display of the ASMs yet, the discussions focused on what data would be useful. Also, various portrayal examples were shown to the stakeholders so that they could give their opinions on the various options.
This test bed is also being used to prototype a transmit architecture for the USACE. The USACE is in the process of implementing the Lock Operations And Management (LOMA) system using AIS AtoN transmitters at each of their locks along the US inland rivers (see Figure 9). The goal is to transmit information such as pool depth, water currents, and lock queue information from these AIS AtoNs using ASMs. Research is also underway into creating models of the currents based upon dam gate opening settings; this information will then be transmitted as well.
Conclusions
The USCG and the USACE have accumulated quite a bit of experience with AIS transmit operations from operating various test beds within the U.S. This knowledge has been used to formulate a recommended architecture to facilitate the creation and dissemination of eMSI using the AIS network. This architecture includes an ASM Manager, which adds capability to the LSS layer that are not currently present: namely to ensure delivery of ASMs, to efficiently manage the VDL, and to prioritize messages to fit within the amount of VDL authorized by the Competent Authority.
References
Burns, William, Gregory W. Johnson, Irene M. Gonin, and Lee Alexander. 2011. “Testing of AIS Application-Specific Messages to Improve U.S. Coast Guard VTS Operations.” In eNavigation Underway. Copenhagen, Denmark.
“e-Navigation Strategic Action Plan.” In. 2012. Washington, DC: The US Committee on the Marine Transportation System.
“Functional Description of the AIS Service components (AISPCU, AIS-LSS & AIS-SM).” In. 2012. Saint Germain en Laye, France: International Association of Marine Aids to Navigation and Lighthouse Authorities.
Gonin, Irene, Gregory Johnson, Ruslan Shalaev, Brian Tetreault, and Lee Alexander. 2009. USCG Development, Test and Evaluation of AIS Binary Messages for Enhanced VTS Operations.” In Institute of Navigation, International Technical Meeting (ION-ITM 09). Anaheim, CA.
Gonin, Irene M., and Gregory W. Johnson. 2009. “Phase 1 Summary Report on AIS Transmit Project (Environmental Message).” In. New London CT: USCG Research & Development Center.
Johnson, Gregory, and Irene Gonin. 2013. “Initial Test and Evaluation of AIS Network Controllers.” In. New London, CT: USCG Research & Development Center.
Johnson, Gregory W. 2009. “Final Summary Report on AIS Transmit Capability for USCG VTS Centers.” In. New London, CT: USCG Research & Development Center. ———. 2010. “AIS Transmit VDL Loading Summary Report.” In. New London, CT: USCG Research & Development Center. Johnson, Gregory, Mark Wiggins, and Irene Gonin. 2012. “Operational Framework for AIS Transmit.” In. New London, CT: USCG Research & Development Center.
“on the AIS Service.” In. 2012. Saint Germain en Laye, France: International Association of Marine Aids to Navigation and Lighthouse Authorities.
“The Provision of Shore Based Automatic Identification System (AIS).” In. 2007. Saint Germain en Laye, France: International Association of Marine Aids to Navigation and Lighthouse Authorities.
“Recommendation on Performance Standards for an Universal Shipborne Automatic Identification System (AIS).” In. 1998. London: International Maritime Organization.
“Technical Characteristics for an Automatic Identification System using Time Division Multiple Access in the VHF Maritime Mobile Band.” In. 2010. International Telecommunications Union, Radiocommunication Sector
(7 votes, average: 2.00 out of 5)
Loading...
Leave your response!