JP7391315B2 - Ship movement sharing navigation support system - Google Patents

Description

The present invention relates to a ship movement sharing navigation support system.

International rules for the safe navigation of ships include the Convention on the International Regulations for Preventing Collisions at Sea (COLREGS) and the International Regulations for the Safety of Human Life at Sea. There are conventions such as the International Convention for the Safety of Life at Sea (SOLAS), and corresponding domestic laws include the Maritime Collision Prevention Act and the Ship Safety Act. These treaties establish basic rules regarding the passage of ships and require certain ships to be equipped with various devices to prevent collisions. Vessels with such obligations are commonly referred to as “SOLAS vessels”

Typical equipment specified by SOLAS uses a frequency band called VHF (Very High Frequency), and is used on ships for distress and safety communications, port communications, telecommunications services, pilotage services, etc. Automatic Identification System uses a wireless communication system called "International VHF" and a dedicated channel in the international VHF band to send and receive signals to automatically identify the status of a ship, such as its position and movements. Automatic Radar Plotting (AIS), which automatically captures the target target, calculates and displays the direction and distance to the target, and automatically determines the risk of collision. Aids: ARPA), etc.

FIG. 1 is a diagram showing an image of the navigational status of a ship and the communication environment. At sea, wired communication is basically not possible, so wireless communication is used. Although satellite communications are primarily used on ships, mobile phone networks may also be available in coastal areas. AIS uses international VHF band channels to digitally communicate data regarding the position and movement of ships between ships. Receiving AIS coast stations are also in operation, and services are being developed to provide received AIS data over the Internet.

Although large ships such as ships of 500 tons or more not engaged in international voyages and ships of 300 tons or more engaged in international voyages are required to be equipped with AIS, non-SOLAS ships such as small ships are not required to be equipped with AIS. Regarding ships, it is not possible to monitor ship movements using AIS. Since many collisions in coastal areas involve pleasure boats and fishing boats, sharing of vessel movement information using communication terminals such as mobile phones and smartphones is also progressing.

Patent Document 1 discloses that AIS information received in the VHF band from ships equipped with AIS and ship information of ships not equipped with AIS received from an information communication terminal equipped with a GPS reception function are aggregated on a main server via the Internet. A ship operation monitoring system that centralizes and distributes data to communication terminals is disclosed.
Patent Document 2 discloses that ship information is acquired from an information distribution device that acquires voyage information of AIS-equipped ships that meet predetermined positional conditions and position information from non-AIS-equipped ships, and an alarm notification zone based on the self-position is created. Disclosed is a communication terminal that outputs a warning regarding a ship that has invaded.

Japanese Patent Application Publication No. 2006-163765 JP2017-102986A

Collision prevention devices such as AIS and ARPA specified by SOLAS are not required to be installed on small vessels that only conduct domestic voyages. Additionally, since a marine license and prescribed training are required to operate a large vessel, such equipment is designed with the assumption that it will be used by trained and qualified personnel. The user interface is not intuitive for users. Furthermore, the use of devices that emit specified radio waves, such as AIS and international VHF, requires procedures under the Radio Law regarding obtaining a license and establishing a radio station, and their use is mandatory for all vessels, including small vessels. We are in a difficult situation.

According to the Maritime Traffic Safety Act and the Port Regulations Act, when construction work that requires traffic restrictions or construction work in congested areas is carried out, a patrol boat must be deployed to ensure the safety of ships navigating near the area where the work is being carried out. It also imposes certain requirements on the crew of patrol vessels. The duties of the patrol vessel include calling attention to ships that are abnormally approaching the implementation area, and if an abnormality is discovered, reporting the information to related parties within the implementation area. Based on the current situation, it is planned to be equipped with AIS and international VHF. However, it is difficult to monitor ships that are not equipped with these equipment and to communicate by voice.

When using information terminals such as those described in the above patent documents, unless more ships are equipped with similar information terminals, the movements of the ships cannot be shared, and collisions can be avoided. It is difficult to judge the behavior of In addition, international VHF is used for voice communication to avoid collisions, but with mobile phone calls and chat functions on smartphone apps, it is not possible to make a call unless the other party can be identified. It is not possible to communicate urgently with unspecified vessels to avoid a collision.

Additionally, there is some reluctance on pleasure boats and fishing vessels to make their location public, and it would be difficult to require non-SOLAS vessels to be equipped with devices that provide location information using AIS or smartphone apps. Therefore, it is necessary to increase the motivation to install communication terminals and promote their widespread use.
The present invention has been made to solve the above-mentioned problems, and provides a ship capable of presenting functions useful for ship collision prevention to more ship operators in a manner that is easier to understand. The objective is to provide a shared navigation support system.

In order to solve the above-mentioned problems, for example, the configurations described in the claims are adopted.

Information that identifies ship operators and ships is linked and managed with ship movement information history, and shared ship movement data converted to a format specified by map data is displayed on the user interface while the ship is maneuvering, so ship collisions can be avoided. Functions useful for prevention can be presented in an easier-to-understand manner, and the history of vessel movement information that identifies the operator and vessel is managed, making it easier for operators and operators to improve safety. Since it will be possible to provide information for improvement and insurance application, it will be possible to provide incentives for more ship operators to use the ship movement sharing navigation support system.

FIG. 2 is a diagram showing an image of the navigational status of a ship and the communication environment. It is a scheme diagram showing a service model. FIG. 1 is a schematic network configuration diagram of the entire system. FIG. 3 is a diagram showing a protocol stack for explaining the relationship between communication devices. FIG. 3 is a functional block diagram of each device in the application layer. FIG. 2 is a diagram showing a use case of a ship movement sharing navigation support system. FIG. 3 is an image diagram of a top screen displayed when an application is executed. It is a diagram showing an example of an account-related table structure and relationships. It is a diagram showing an example of a ship-related table structure and relations. This is an example of a ship operator information management screen. This is an example of a ship information management screen. This is an example of a project information management screen. FIG. 3 is a diagram showing an example of a plot-related table structure and relations. It is a figure explaining the layer structure of a map display screen. FIG. 3 is a diagram showing the relationship between the scale of map display and the display mode of ship icons. FIG. 3 is an image diagram of a map display generated on a screen using a layer configuration. It is a flowchart which determines whether a ship icon can be displayed. It is an image diagram of a map screen displaying a heat map. It is an image diagram of a collision prediction screen. 3 is a flowchart showing processing related to radar mode display. It is a flowchart which shows warning target ship extraction processing. It is a flowchart which shows caution target ship extraction processing. FIG. 3 is a diagram illustrating a screen image that presents virtual wireless functions to a user. FIG. 3 is a sequence diagram showing processing from connection to standby. FIG. 3 is a sequence diagram showing processing during a PTT call. This is a screen image of a land management terminal running a group radio function. FIG. 3 is a sequence diagram showing processing related to group radio. It is an image diagram of a route reproduction animation. FIG. 3 is a diagram schematically showing the flow of processing from the start to the end of ship maneuvering. This is an example of a display of a ship operation history of a certain ship operator. This is an example of displaying ship operation history in a project. This is an example of a plot creation screen for setting a monitoring area. FIG. 2 is a diagram illustrating a data structure regarding position information and ship information registered as a monitoring area. This is an image of the screen displayed on the app when a vessel in transit approaches the monitoring area. This is an image of the screen displayed on the app when a vessel in transit approaches the monitoring area. It is a flowchart which shows the process of detecting a ship approaching a monitoring area. 7 is a flowchart of processing regarding a warning area document. FIG. 7 is a diagram illustrating an example of displaying a warning on a browser used by a land-based administrator.

Hereinafter, embodiments will be described using the drawings.
[1 Overall system configuration]
[1.1 Service model]
First, the usage form of the vessel movement sharing navigation support system will be explained. FIG. 2 is a schematic diagram showing a service model. A service provider 10 provides a service using a ship movement sharing navigation support system, and includes a ship operator 20 who operates the ship, an operator 30 who operates the ship, and a contractor 40 who performs construction work that involves the operation of the ship. , an insurance company 50 that provides ship insurance, and a water area manager 60 that manages water areas that require regulations regarding the operation of ships, such as ports, construction areas, fishing net installation areas, etc., use the service provided by the service provider 10. are doing.

In addition to SOLAS vessels, vessels that require collision prevention measures include not only small vessels for personal use such as pleasure boats, but also commercial vessels such as fishing vessels, work vessels, and patrol vessels. From another perspective, vessel movement information can be used as verification data and statistical data in insurance accident verification and rate calculations. Furthermore, in ports, it is necessary to manage the movement and berthing positions of ships entering and exiting on a busy schedule, and in fishing and construction work, not only collisions between ships, but also fishing-related equipment such as fixed nets and aquaculture rafts and construction work must be managed. It is also necessary to prevent collisions with obstacles such as related equipment. As described above, there are a wide variety of stakeholders who require information regarding vessel movements, and therefore, as shown in Figure 2, various entities are assumed to be service users.

The service provider 10 also receives information from an external information provider 70 to provide services, and the information provided from the information provider 70 includes, for example, map information, weather information, ship movement information, and marine accident information. etc.
The vessel operator 20 may use the service as an individual 21, but may also be an employee 22 who provides services to the operating company 30. Further, the operating company 30 may also be a cooperating company (subcontractor) 31 that provides services to the construction company 40. Due to these differences in business models, various contract forms exist between the service provider 10 and each user.

[1.2 Network configuration]
[1.2.1 Overall configuration]
Next, the network configuration of the vessel movement sharing navigation support system according to the embodiment will be described. FIG. 3 is a schematic diagram of the network configuration of the entire system. The ship movement sharing navigation support system is mainly provided by the functions of the management server 100. The management server 100 is connected to the Internet IN, and provides information such as vessel movement to the communication terminal 200 and the land management terminal 300 using the Internet protocol (IP). Since the communication terminal 200 is assumed to be used by the boat operator 20 on a boat, the communication terminal 200 is used on water such as the sea or a river. Since a wired data network cannot be used on the water, data communication with the management server 100 is performed via a carrier network CN through which a communication carrier such as a mobile phone company or a satellite communication company provides data communication services.

On the other hand, the onshore management terminal 300 is assumed to be used by a manager of the operating company 30 or the construction contractor 40 in an onshore office, and performs data communication with the management server 100 via the Internet IN. Note that it is also conceivable that the onshore management terminal 300 is installed on an in-house network of the operating company 30 or the like, and for example, data linkage may be performed with another in-house system 301 that manages employee information and the like. Further, data communication between the communication terminal 200 and the land management terminal 300 may be performed by a private network PN using a long-distance wireless LAN (Local Area Network), etc., and by connecting to the Internet IN via the private network PN, A configuration in which the management server 100 is accessed may also be used.

The movement information of the ship is grasped based on the information included in the AIS signal emitted by the AIS transceiver 800 and the position information determined by the function of the communication terminal 200, as will be explained in detail later. Here, the AIS transceiver 800 is a device that transmits and receives AIS information according to communication methods and message formats compliant with standards such as SOLAS, ITU (International Telecommunication Union), and IEC (International Electrotechnical Commission). The AIS information includes ship information such as a ship identification code, ship name, position, course, speed, and destination in a predetermined format. On the other hand, the land AIS receiver 810 and the marine AIS receiver 900 in this embodiment are devices that receive the AIS signal from the AIS transceiver 800, convert it into a predetermined data format, and then transmit the data.

[1.2.2 Protocol stack]
Here, FIG. 4 is a diagram showing a protocol stack for explaining the relationship between the communication devices shown in FIG. 3. The AIS transceiver 800 transmits signals that comply with the physical layer (L1) and data link layer (L2) protocols specified by ITU-R M.1371, IEC 61993, IEC 62287, etc., and transmits signals to the land AIS receiver 810. and maritime AIS receiver 900 interprets the signals received from AIS transceiver 800 according to these protocols. In the application layer, the AIS transceiver 800 transmits positioning data of own ship's position and ship name generated using Global Navigation Satellite System (GNSS) such as Global Positioning System (GPS). It also transmits information related to its own ship, such as the MMSI number and MMSI number (Maritime Mobile Service Identity), to other ships, and displays the information received from other ships on a user interface such as a plotter. In general, the standards established by the National Marine Electronics Association (NMEA) (registered trademark) are adopted as a common format for data such as AIS and GPS used in ship operations, and are used for positioning equipment. Communication is performed between the display device and the AIS transceiver using a serial communication protocol.

The land-based AIS receiver 810 transmits the AIS data received from the AIS transceiver 800 to the management server 100 over the IP network using a reception/transmission program running on the application layer. Further, the marine AIS receiving device 900 transmits the AIS data received from the AIS transceiver 800 to the communication terminal 200 using BLE (Bluetooth Low Energy) (registered trademark).

The communication terminal 200 such as a smartphone or tablet uses Wi-Fi (registered trademark) as a wireless communication means for IP network communication in addition to LTE (Long Term Evolution) (registered trademark) provided by a mobile phone network. It is installed. Furthermore, the communication terminal 200 is configured to be able to use positioning data generated from GPS etc., base station information, etc. on an application (app), and the AIS information received from the maritime AIS receiving device 900 via BLE communication. The information and positioning information can be sent to the management server 100 over the IP network as ship information. Note that the receiving means such as GPS may be a device built into the communication terminal 200, or may be an external device connected by wire or wirelessly.

The management server 100 and the land management terminal 300 may be general-purpose ones, and the physical layer (L1) and data link layer (L2) may be configured in accordance with either wired or wireless communication standards. The management server 100 has a web server, a database (DB), an API (Application Programming Interface), etc. running in the application layer, and functions as a server that uses the communication terminal 200 and the land management terminal 300 as clients. The protocol used in the application layer may be one that is widely used, such as HTTP.

Note that the use of the VHF band used for AIS requires a license depending on the transmission output, etc., but for Wi-Fi and BLE, as long as equipment that has been certified as conforming to technical standards is used, the license is required for wireless stations. Unlicensed bands are available that do not require a license. When using communication services provided by telecommunications carriers, such as the LTE band, the use of frequency bands is based on a comprehensive license obtained by the telecommunications carrier. Note that the communication standards provided by communication carriers are not limited to LTE as exemplified in this embodiment, but also mobile standards such as WiMAX (Worldwide Interoperability for Microwave Access) (registered trademark) and 5G (fifth generation mobile communication system). It may be a communication standard in a physical communication network or a data communication standard in satellite mobile communication.
The method of wireless communication between devices is not limited to the form shown in FIG. 4, and can be selected as appropriate depending on the range of radio waves, the presence or absence of a license, etc. In any case, any communication method may be used for the lower layer as long as it is possible to send and receive data to and from the management server 100 over the IP network.

[1.2.3 Application layer functional configuration]
FIG. 5 is a diagram showing components in each device in the application layer using functional blocks. There is a communication terminal 200 and a land management terminal 300 as clients of the management server 100, and the configuration appropriately distributes processing performed on the server side and processing performed on the client side, taking into consideration factors such as processing capacity and network traffic of each. It becomes. In this embodiment, the configuration is such that edge computing is performed in which high-load processing is executed on the client side and the amount of data on the network is suppressed.

Note that the application software installed on the client-side communication terminal 200 is generally called a "native application" (abbreviated as "app" in this embodiment), and is provided on the browser of the land management terminal 300. Application software that executes these functions is generally called a "Web application" (abbreviated to "Web" in this embodiment). In this embodiment, the functions provided by application software that present data to the user and allow operation input from the user are collectively referred to as a "user interface." In addition, the various hardware, software, and other components that provide a user interface are collectively referred to as the "front end," and the various components that are executed on the server side that are not directly operated by the user are collectively referred to as the "back end." In this embodiment, by loosely coupling components using APIs, it is possible to configure a highly extensible system without being restricted by the programming language or framework used in the front end and back end. There is.

Each component will be explained in more detail below. On the management server 100, there is an API server 110 that provides a service to connect the front end and the back end, a web server 120 that provides a service to the browser 310 as a front end, and data management and connection functions for the front end. An audio server 130, a data store 140, a database 150, and a backend service 160, which serve as various backends for providing the AIS data, and an AIS reception server 170 that receives AIS data are constructed. Note that the management server 100 may be constructed within a specific data center, or may be constructed on PaaS (Platform as a Service) provided on a so-called cloud service.

The communication terminal 200 includes a positioning program 210 that provides a positioning function and an application 220 that provides a user interface function, and the land management terminal 300 includes a browser 310. Map information displayed on the application 220 and the browser 310 is generated based on map data 710 provided from the information providing server 700. The map data 710 may be nautical chart data created as a nautical chart, map data including information on land and sea, or data that can be used as Geographic Information System (GIS) data. You can use For example, GeoJSON, which describes geometry and features as a group of objects, can be used as a geospatial data exchange format for describing GIS data. The map data 710 may be downloaded in advance from the information providing server 700 to the communication terminal 200 or the land management terminal 300, or may be read as appropriate depending on the current location.

The reception/transmission program 811 on the land AIS receiver 810 transmits the AIS data received from the AIS transceiver 800 to the management server 100, and the reception/transmission program 901 on the maritime AIS receiver 900 receives the AIS data from the AIS transmitter/receiver 800. The AIS data thus obtained is transmitted to the communication terminal 200.
The API server 110 on the management server 100 is a server that provides an API for connecting to a backend service to an application 220 and a browser 310, which are user interfaces, and FIG. 5 shows the API provided in this embodiment. Representative APIs are listed. AIS controller 111 is an API that stores AIS data received by AIS reception server 170 in data store 140 and database 150. The plot controller 112 , operator controller 113 , vessel operator controller 114 , image controller 115 , vessel controller 116 , and voyage controller 117 register and delete data based on operations in the app 220 and browser 310 , and perform operations on the app 220 and browser 310 . This is an API that provides data, etc.

The web server 120 is a server that provides a web application that implements functions on the browser 310, and the functions provided in this embodiment include a virtual wireless function 121, a plot creation function 122, as will be explained in detail later. There are an information management function 123, a map display function 124, a history output function 125, and the like.
The voice server 130 is a server that provides a virtual wireless function, and in this embodiment, WebSocket, which connects a client and a server at high speed using Hypertext Transfer Protocol (HTTP), is used as a communication protocol. There is.

The data store 140 is a real-time data store generally referred to as a real-time database, NoSQL cloud database, cloud data store, etc., and stores data for performing highly real-time processing on the front side of the web server 120, application 220, and browser 310. The database 150 is a storage device configured as a relational database, an example of which will be explained in detail later. The backend service 160 provides backend service functions such as access to the data store 140 and database 150 and authentication processing.
The AIS reception server 170 is a server that receives AIS data from the reception/transmission program 811 of the land-based AIS reception device 810, and is connected to the land-based AIS reception device 810 using UDP (User Datagram Protocol).

A positioning program 210 included in the communication terminal 200 generates position information data based on a positioning signal received by a GNSS antenna such as a GPS installed in the communication terminal 200 or a signal from a base station. The application 220 is equipped with a position information reception/transmission function 221 that generates and transmits own ship position information data based on the position information data generated by the positioning program 210. The own ship position information data used and transmitted to the management server 100 is used as ship movement information of other ships in the application 220 on the other communication terminal 200. The position information receiving and transmitting function 221 also has a function of calculating the ship speed and course from the difference in the position information in addition to the position information of the own ship, and transmitting the calculated ship speed and course to the management server 100.
The application 220 also includes a plot creation function 222, an information management function 223, a map display function 224, a collision prediction function 225, a history output function 226, a virtual radio function 227, etc., which will be described in detail later.

[2 Data structure]
[2.1 Use case]
In explaining the data structure according to this embodiment, a use case of the vessel movement sharing navigation support system will be explained with reference to FIG. In the use case, the users are assumed to be a ship operator who operates a ship on the water, and a manager who manages operations on land. The ship operator has the following functions: ``Share vessel movements,'' ``Manage information,'' ``Predict collisions,'' ``Contact other vessels,'' ``Record voyage information,'' and ``Create plots.'' The use case is envisaged. On the other hand, since managers do not operate ships, the use case of ``predicting collisions'' is excluded compared to ship operators.

"Share ship movements" allows you to share movement information about the movement or halted status of ships, such as the position, speed, and course of your own ship and other ships, by displaying them on a map. "Manage information" allows the system to manage account-related basic information such as the name and contact information of the ship operator and company, as well as ship-related static information such as the ship's name and ship registration number. In ``Predict a collision,'' the system receives a warning from the system regarding the relative relationship between your own ship and other ships, the position and distance of ships that are likely to collide, and the estimated time until collision. ``Contact other ships'' attempts voice communication between ships to avoid collisions. Then, in "Create a plot", make settings to provide information on the map as a point or area. The plot may include, for example, information that warns or calls attention to a ship operator, information that is useful for ship operation, information that requests rescue in the event of a marine accident, and the like.

Here, FIG. 7 is an image diagram of the top screen displayed by the application 220 on the communication terminal 200 used by the vessel operator. On the map, icons and ship names indicating ship positions, plot positions, plot names/area names, nautical chart formats (symbols), names, etc. are displayed.
Among the icons representing ships, SI1 in the figure represents the own ship. On the own ship icon SI1, an icon indicating the usage status of the virtual radio, which will be explained in detail later, is displayed. As icons indicating other ships, SI2 indicating a stopped state and SI3 indicating that the vessel is sailing are displayed. The other ship icons SI2 and SI3 both have red and green dots that look like sidelights placed on the side of the ship, allowing the ship operator to intuitively understand the port and starboard sides of the other ship. provided. Further, when comparing the side lights of the stopped ship icon SI2 and the sailing icon SI3, the sailing icon SI3 has a shape that is illuminated. This makes it easy to intuitively grasp the presence of other ships navigating. Further, a speed vector line corresponding to the ship speed and course is displayed in the bow direction of the navigation icon SI3, and a wake line is displayed in the stern direction. This information can be selectively displayed for the own ship and other ships, making it easy to understand the movement of the ship.

As shown in FIG. 7, various buttons are displayed on the screen to accept operations from the user. Specifically, menu button B1 instructs to display a menu, plot button B2 to display a plot creation menu, virtual radio button B3 to instruct panel display for virtual radio, and move own ship's current position to the center on the map. A current position button B4 that instructs the user to proceed with the collision prediction, a radar mode button B5 that instructs the user to transition to the radar mode screen that shows the user information regarding collision prediction, and a ship maneuvering status button B6 that instructs the user to start or end maneuvering of own ship are displayed. ing. Note that the ship maneuvering status button B6 may be displayed in a specific manner such as a different color while the ship is maneuvering.

[2.2 Database table structure]
Here, the table structure of the database configured to provide the above-mentioned functions will be explained. The database 150 is a relational database in which a ship operator, a ship, etc. is uniquely identified by an identifier (ID), and is linked to various information as described below.

[2.2.1 Account-related table structure]
FIG. 8 is a diagram showing an example of an account-related table structure and relationships. As shown in FIG. 2, accounts can be issued to each of the ship operator 20, the operating company 30, the construction company 40, the insurance company 50, and the water area manager 60. In this embodiment, in order to manage the ship operation history for each individual ship operator 20, an account (ship operator ID) is issued for each natural person who operates the ship. An operating company 30 that manages the operator 20 as an employee, an insurance company 50 that acquires information about the operator 20 based on contractual rights and obligations, and an insurance company 50 that acquires information about the operator 20 based on legal and contractual rights and obligations. The water area manager 60 who monitors the ship operation status is issued an account (business ID) for each business operator. In addition, projects such as construction in which a joint venture (JV) between multiple operators or a construction contractor 40 as a single company operates with multiple operating operators 30 as partner companies are managed as projects with a fixed period. An account (project ID) will be issued for each project. These company IDs and project IDs can be linked to the vessel operator ID and used for management to identify the group to which the vessel operator belongs.

As shown in Figure 8, the basic information of entities identified by the operator ID, operator ID, and project ID is managed in the "vessel operator table," the "operator table," and the "project table," respectively. . In order to identify and manage businesses participating in each project, a "project business operator table" is set up to manage project IDs and business operator IDs in a linked manner. The "project operator table" is further linked with a "project ship operator table" and a "project ship table" for identifying and managing ship operators and ships operating in the project by ID.

A "license table" that manages information regarding the boat operator's boat license is linked to the boat operator ID, and the license number, expiration date, etc. can be managed. In addition, the "vessel maneuver history table" linked to the vessel operator ID records the start/end time and distance of each vessel maneuver, and in addition to identifying the vessel operated by the business ID and project ID, the vessel ID, By specifying the operated vessel, role, etc. using the vessel operation purpose ID, role ID, etc., it is possible to manage the boarding history.

[2.2.2 Ship-related table structure]
Continuing on from this, FIG. 9 is a diagram showing an example of a ship-related table structure and relations. A ship is uniquely identified by a ship ID, and in addition to static information such as ship name and ship number, in this embodiment, a "location publication flag" indicating whether or not to publish the ship's position on the map is used. is also set. As a result, for ships that do not publish their positions, it is possible to display their positions on the map within the range necessary to prevent ship collisions.

The "voyage history position table" linked to the ship ID is a table that manages dynamic information during the voyage, such as destination, latitude, longitude, heading, course, ship speed, movement judgment, etc., along with data acquisition date and time as a history. By linking the ship operator ID, business operator ID, project ID, ship operation history ID, etc., it is possible to manage relationships with ship operators and businesses.

Further, attribute information of ships is managed and normalized by ship type ID and ship size ID. In this embodiment, the ship icons displayed on the map are prepared as image data with illustrations that can be associated with the ship type, as shown in an example of a cargo ship in FIG. In addition to general ship types such as cargo ships and tankers, there are also "own ship" icons that indicate that the ship is owned by the company, and "app ship" icons that indicate that the ship is equipped with the communication terminal 200. You can. In this embodiment, as will be described in detail later, while these ship type icons are displayed in a normal display mode, ship icons in different display modes are used depending on the display range and mode of the map.
In addition, the display size of the ship icon is controlled so that the relative relationship between the scale on the map and the size of the ship is maintained, and as illustrated in Figure 9, the "ship size table" The display size of the icon can be determined based on data indicating the total length and type width of the managed vessel.

Here, FIG. 10 is an example of a ship operator information management screen, which is a user interface for referring to and inputting information regarding a ship's license together with basic information of a ship operator. The data input here is stored in the "vessel operator table" and "license table" illustrated in FIG. 8. An image file of a photographed driver's license is specified by an image ID in the "license table".

Next, FIG. 11 is an example of a ship information management screen, which serves as a user interface for referring to and inputting information regarding ship size and ship type, as well as basic ship information. It is also possible to register images of the exterior of the ship and images of ship inspection certificates, and the data entered here can be stored in the "Ship Table", "Ship Type Table", and "Ship Type Table" as shown in Figure 9. It is stored in "Ship Size Table" etc.

Figure 12 is an example of the project information management screen, which displays the basic information of the project as well as the list of businesses participating in the project, basic information for each business operator, and the ship operators assigned to the project. This is a user interface for viewing information about ships. Accounts identified by project IDs are allowed to change the basic information of the project managed in the "project table", but are only allowed to read information about the operators and ships assigned by the operator. It has not been done.

[2.2.3 Plot-related table structure]
Next, FIG. 13 is a diagram showing an example of a plot-related table structure and relations. A plot is identified by a plot ID, and is associated with a plot category indicating the type of plot, location information of an object whose information should be shared by the plot, and an image file of the plot object. Similar to ship icons, plots also have icons corresponding to plot categories as images, and as illustrated in Figure 13, there are icons corresponding to nautical chart symbols such as "lighthouse" and icons for "floating objects". There are icons that indicate temporary situations.

Specifically, depending on the plot type, there may be less volatile information that indicates permanent objects, such as chart symbols or marina locations, but there may also be less volatile information that indicates permanent objects, such as floating objects or patrol vessels. There is also highly volatile information that indicates things. Weather and sea conditions such as strong winds and waves are also phenomena that change over a relatively short period of time. On the other hand, there are some targets, such as construction areas, that are relatively long-term but limited in duration. If an object that no longer exists at that location or an event that has expired for a specified period of time is displayed on the map indefinitely, it may prompt unnecessary warnings to the vessel operator, which may actually impede safe vessel operation. . In this embodiment, a display deadline flag is provided as one item of the "plot category table" to indicate the presence or absence of a display deadline, the length of time, etc. according to the attribute of the plot, and the "plot table" includes the date and time of the display deadline. is now registered. The display deadline may be specifically specified by the user when creating the plot, or may be automatically calculated according to the type of display deadline flag.

In addition, in the "Plot Table", a "Plot Type Flag" is set to identify whether a plot point consisting of position information is specified at one point or a plot is specified by multiple plot points. When specified by points, it can be displayed on the map as a vector figure composed of straight lines with a plurality of plot points as vertices, such as the figure described as "fixed net" illustrated in FIG. Note that the vector figure may be a curved line having a plurality of plot points as control points.

[3 Functions of ship movement sharing navigation support system]
Hereinafter, the main functions of the vessel movement sharing navigation support system according to this embodiment will be explained.
[3.1 Map display function]
[3.1.1 Layer structure]
FIG. 14 is a diagram illustrating the layer structure of the map display screen displayed on the communication terminal 200 and the land management terminal 300. Above the map layer where the base map data is displayed, there is a heat map display area where statistical information regarding predetermined items is visually displayed as a heat map. There is an area display layer that is displayed as a graphic, and above that there is an information icon display layer that displays a plot information icon specified by a single plot point as a raster image. Furthermore, a ship icon display layer, a ship name display layer, a track display layer, and a speed vector display layer are stacked on top of that, and in addition to displaying only the ship, it is also possible to selectively display the track and speed vector. It becomes. When the radar mode screen is selected, there is a warning display layer that displays caution and warning areas on the ship icon to prevent ship collisions, and further above that layer, there is a warning display layer that displays caution and warning areas for preventing ship collisions, and further above that layer, there is a warning display layer that displays a warning area on the ship icon. A wireless icon display layer is arranged to indicate the status of the wireless device.

In this embodiment, as illustrated in FIG. 15, the display form of the ship icon is changed depending on the scale of the map. When a wide-area map is displayed on a small scale, a large number of ship icons are displayed within the display range, but if all icons are displayed uniformly, the icons will be displayed in an excessively dense manner. Therefore, ships that are sailing are displayed using the ship type icon shown in the illustration above, but ships that are at anchor are displayed using a grain icon (circle), and if there are duplicate ship icons, the number of ship name text displayed is By limiting the amount of information displayed, we aim to reduce the amount of information displayed.

When displaying a mid-range map at a medium scale, all vessels to be displayed are displayed using a ship type icon, but as mentioned above, an icon with a lighted sidelight is used for a ship that is sailing. , an icon representing a ship at anchor with its sidelights turned off is used. These ship type icons are adjusted and displayed in a size corresponding to the ship size registered in the database 150, depending on the scale of the map.

When displaying a detailed map at a large scale, the amount of change in ship position information increases, so regardless of the ship type, polygon ship icons are generated as polygons that are a combination of vector shapes such as simple pentagons and triangles. Is displayed. This reduces the processing load required to display ship icons and enables smooth map display in response to changes in ship position information. Similarly to the ship type icons, the polygon ship icons are also displayed adjusted to a size corresponding to the ship size registered in the database 150, depending on the scale of the map.

Here, FIG. 16 is an image diagram of a map display generated on the screen using the layer configuration illustrated in FIG. 14. In this example, the ship name is displayed in text along with the ship icon, and a speed vector is also displayed in the bow direction of the ship icon that is sailing, but no wake is displayed for any of the ships. That is, the necessity and display mode of individual information can be controlled for each layer, and this is an example when the display of the track display layer shown in FIG. 14 is turned off.
A ship image, ship name, movement information, etc. are displayed in association with the ship icon, and images and comments are displayed in connection with the "floating object" icon, but these detailed information can be accessed by tapping the icon. You may also be able to select whether to turn the display on or off.

By the way, the ship icon SId displayed with a dotted line in FIG. 16 means a ship whose position is not made public. When operating fishing boats, pleasure boats, etc., there are some operators who do not want their own vessel's position to be made public, but in order to prevent vessel collisions, it is necessary to keep track of the position and movements of other vessels that may collide. Needs to be monitored. The Maritime Collision Prevention Law stipulates the actions that should be taken when maneuvering depending on the type and condition of the vessel, as ``navigation methods for vessels that are within the visual field of each other.'' Therefore, in this embodiment, control is performed such that ships located in positions that are considered to be visible from the own ship are displayed on the map, but ship icons located outside the visual range are not displayed. Note that the visible distance actually varies depending on the height of the operator's seat from the sea level and the weather and sea conditions, but for example, it is defined as the distance at which the mast light can be seen under COLREGS and the Maritime Collision Prevention Act. It may be set to about 6 nautical miles (approximately 11 km).

In addition, the interval at which movement information is transmitted by AIS is determined to range from 2 seconds to 3 minutes depending on conditions such as ship speed, but if movement information is not updated beyond this time interval, , there is a possibility that the AIS data of the ship in question cannot be received properly. If AIS data is being received normally, the status will be sent every 3 minutes even if the vessel is at anchor or at anchor and is not moving at 3 knots or more. If the information is not updated, the vessel may have already moved to another location, or incorrect data may have been recorded for some reason. Therefore, in this embodiment, among the position information extracted as other ships that should be displayed on the map, if the data was acquired within 7 minutes, a normal icon is displayed, but if the data is acquired within 7 minutes, it is suspicious. Other ships are displayed as gray icons to indicate to the operator that they are information, and if the time period exceeds 10 minutes, they are not displayed on the map. Note that this criterion is not necessarily limited to 7 minutes or 10 minutes, and may be set to a shorter or longer time.

[3.1.2 Determination of whether ship icon can be displayed]
FIG. 17 is a flowchart for determining whether a ship icon can be displayed. When the process starts, first, the position information of the own ship is acquired from the data store 140 (S101), and then the information of other ships existing within the display range of the screen is acquired from the data store 140 (S102). Here, the following steps S103 to S106 are repeatedly executed for the number of ships for which information has been acquired.

First, the position announcement flag of the vessel to be determined is referred to, and if it is determined that the vessel does not publish its position (S103; No), then whether or not the vessel is within visual distance from the own vessel's position is determined. It is determined whether (S104). If it is determined that the other ship does not exist within the visible distance (S104; No), the ship icon of the other ship is not displayed on the map (S105).

On the other hand, if it is determined in step S104 that the ship is within visible distance from the own ship (S104; Yes), or if it is determined in step S103 that the position should be made public (S103; Yes), then the other ship It is determined whether the location information was acquired within 10 minutes by referring to the time when the location information was acquired (S106), and if it is determined that the location information is not acquired within 10 minutes (S106; No), then Other ships are hidden (S105). On the other hand, if it is determined that the location information was acquired within 10 minutes (S106; Yes), then it is determined whether the location information was acquired within 7 minutes (S107). . Here, if it is determined that it has not been within 7 minutes since the location information was acquired (S107; No), the other ship will be displayed with a gray icon (S108), indicating that it has been within 7 minutes. If it is determined (S107; Yes), the other ship is displayed with a normal icon (S109).

[3.1.3 Heat map]
Figure 18 is an example of displaying a heat map. On the map, circles with sizes and colors corresponding to numerical values corresponding to specified information are displayed as a heat map, and in addition, ship icons, Wireless icons, information icons, etc. are displayed. In the example shown in this figure, a route as nautical chart information is displayed as an information icon, and circles in the heat map indicate the amount of fishing boats in a predetermined period. The Maritime Traffic Safety Act stipulates that certain large vessels are required to navigate the shipping lanes, but there are exceptions to the navigation regulations for fishing vessels that are engaged in fishing, so this information is displayed for the purpose of understanding trends in the traffic volume of fishing vessels. has been done. Note that the type, amount, period, etc. of information to be displayed as a heat map can be arbitrarily set, and the display form is not limited to circles, but polygons, lines, etc. may also be used.

[3.2 Collision prediction function]
[3.2.1 Screen image]
Next, the collision prediction function will be explained. FIG. 19 is an image diagram of a collision prediction screen displayed on the communication terminal 200. The screen illustrated in this figure is named "radar mode" in this embodiment, and similarly to the display screen of a ship's radar, numerical values indicating the direction are arranged on a circle centered on the own ship. This mode displays the movement information of other ships as icons. In the example of FIG. 19, other ships on the radar mode screen are displayed not with icons corresponding to ship types or ship sizes, but with simple figures such as circles and triangles and speed vectors.

In the example shown in Figure 19, the course-up display shows the own ship's course of 225° at the top, but the north-up display instructs to change to the north-up display, which shows north (0°) at the top. A button Bnu is provided. Near the own ship icon, the ship name, speed and course of the own ship are displayed in text.
Furthermore, two types of fan shapes are displayed centered on the coordinates of the own ship: a first fan shape F1 meaning a warning area and a second fan shape F2 meaning a caution area. The first sector F1 has a radius corresponding to the distance reached in a predetermined time (first time) if the current ship speed and course are maintained, and it spreads in the direction of ±5° from the own ship's course. It is fan-shaped with a central angle of 10°. This first sector F1 is used as a warning area for detecting a warning target. The first time is, for example, 5 minutes or 3 minutes, and is appropriate for recognizing the relationship between your own ship and other ships and determining whether your own ship needs to maintain its course or take avoidance action. The time will be set.

In this way, by predicting collisions by assuming an area that extends to a certain extent from the ship's course as an area where there is a high possibility that the ship will navigate within a predetermined time, it is possible to predict the movement of other ships as well as waves, wind, etc. It is possible to make collision predictions that take into account course deviations due to the influence of external disturbances. Note that the length of the radius and the angle from the course are not necessarily limited to the values mentioned above, and may be adjusted depending on the weather and sea conditions, or depending on the type of ship, current speed, maneuverability, etc. It may be adjusted accordingly. Furthermore, it may be possible to allow the boat operator to set it arbitrarily.

In this embodiment, when another ship exists within the range defined by the warning area, that is, the first fan shape, and when the warning area of the own ship and the warning area of the other ship overlap, and predetermined requirements are met. Sometimes, these other ships are displayed on the screen as warning target ships. In this way, when a warning target ship exists, the warning area is displayed using a warning color, such as red, which is generally associated with a warning, and the warning target ship is also displayed in a warning color.

The second sector F2 has a radius corresponding to the distance reached in a predetermined time (second time) if the current speed and course are maintained, and the radius is ±112.5° from the own ship's course. It is a fan shape with a central angle of 225° that spreads out in all directions. This second sector F2 is used as a caution area for detecting a target of attention. The second time is, for example, 3 minutes or 1 minute 30 seconds, and is used to detect the presence of a vessel that may pose a risk of collision if the own vessel changes course (potential warning target vessel), or Pay attention to the existence of ships that are navigating without taking ship movements into consideration and that may require your own ship to take cooperative action to avoid collision (vessels that require cooperative action). Appropriate time will be set to encourage this.

According to COLREGS and the Maritime Collision Prevention Act, the illumination range of a side light is defined as 112.5 degrees on each side from the ship's heading, and these angles correspond to the range that is recognized by other ships as the starboard and port sides of the own ship. As for the ``navigation method for ships that are within the field of view of each other'', ``When two power-powered ships cross each other's courses and there is a risk of collision, a power-powered ship that looks at the other power-powered ship on its starboard side. shall avoid the path of such other power-powered vessel.'' The ship that sees the other ship's port side (red side light) becomes the give-way ship, and in principle, it is necessary to take avoidance action, but if it is recognized that the collision cannot be avoided by the give-way ship's actions alone, the collision may be avoided. It is necessary to take cooperative actions to avoid it. Therefore, even if your own ship is a holding ship, by displaying a caution area that is assumed to be an area where you should take precautions regarding avoidance maneuvers of other ships, you can provide support to ship operators to avoid collisions with other ships. It becomes possible to do so.

As with the first sector, the length of the radius and the angle from the course are not necessarily limited to the values mentioned above, and may be adjusted depending on the weather and sea conditions, or depending on the type of ship and current It may be adjusted according to the ship's speed, maneuverability, etc. It may also be possible to allow the boat operator to set it arbitrarily.
In this embodiment, if other ships exist within the caution area, that is, within the range defined by the second sector, these other ships are displayed on the screen as caution target ships. In this way, when a caution target ship exists, the caution area is displayed using a caution color that is generally associated with caution, such as yellow or orange, and the caution target ship is also displayed in a caution color. .
Non-warning ships that do not fall under either warning or caution targets are displayed in cool non-warning colors such as blue or green, and if there are only non-warning ships nearby, the warning area of your own ship is displayed. The warning area and the warning area are also displayed in a non-warning color.

[3.2.2 Warning display processing]
Details of the process for displaying other ships, warning areas, and caution areas illustrated in FIG. 19 will be described below with reference to flowcharts in FIGS. 20 to 22.
FIG. 20 is a flowchart showing processing related to radar mode display. Although this process is executed on the application 220 side in this embodiment, it may be executed on the management server 100 side.

When the process starts, ship information such as own ship's position information, ship speed, and course is acquired from the data store 140 (S201), and then the own ship's position coordinates and speed vector in the map display coordinate system are calculated. (S202), and the above-mentioned warning area and caution area of the own ship are calculated centered on the position coordinates of the own ship (S203). Next, information on other ships existing within a certain range is acquired from the data store 140 (S204). The fixed range may be set as appropriate, such as a range corresponding to 0.1° latitude (approximately 11 km), a display range on the screen, or the like. Here, the following warning target ship extraction process (S210) and caution target ship extraction process (S220) are repeatedly executed for the number of ships for which information has been acquired.

FIG. 21 is a flowchart showing the warning target ship extraction process. First, it is determined whether the target ship is located within the own ship's warning area, that is, within the area calculated as the first sector (S211), and if it is determined to be within the warning area (S211; Yes) , the other ship is displayed as an icon indicating that it is a warning target (warning target ship) (S212), and the calculated distance from the own ship to the warning target ship and a text message prompting the operator to warn are displayed. A process is performed (S213). Then, the first sector of the own ship is displayed in a warning color (S214), and the process ends.

If it is determined in step S211 that the determination target ship is not located within the own ship's warning area (S211; No), then whether or not the determination target ship's warning area overlaps with the own ship's warning area is determined. A determination is made (S215). In the example of FIG. 19, the warning area of "Maru X" overlaps with the warning area of the own ship. Here, if it is determined that the warning area of the determination target ship overlaps with the warning area of the own ship (S215; Yes), it is determined whether the other ship is approaching (S216). If the warning areas overlap but the courses do not intersect, there is no need to issue a warning because the other ship is moving away from the own ship. Furthermore, even if the routes are scheduled to intersect, if a warning is given when it is a considerable amount of time away, the effectiveness of the warning may be diminished. Therefore, if it is determined that the other ship is approaching (S216; Yes), it is determined whether or not they will intersect within a certain time (S217), and if it is within a certain time (S217; Yes). ), the predicted time until the crossing and a text message prompting a warning are displayed (S218), and the process moves to the process of S214, where the first sector of the own ship is displayed in a warning color.
If the determination results in steps S215, S216, and S217 are all No, there is no need to display the other ship as a warning target at this stage, so the first sector of the own ship is displayed in a non-warning color. (S219), and the process ends.

FIG. 22 is a flowchart showing the caution target ship extraction process. When the process is started, it is determined whether or not the vessel to be determined has been processed as a warning target vessel in step S210 (S221), and if it is already a warning target vessel (S221; Yes), the warning target vessel is The extraction process ends. On the other hand, if it is determined that the ship is not a warning target ship (S221; No), it is determined whether or not the ship is located within the caution area of the own ship, that is, the second sector (S222). Here, if it is determined that the ship is within the caution area (S222; Yes), a process is performed to display the ship as a caution target ship on the screen (S223), and A process is performed to display the distance to the ship and to alert the operator of the ship (S224). Then, the second fan shape of the own ship is displayed in the caution color (S225), and the caution target ship extraction process ends.
If it is determined in step S222 that the ship is outside the caution area (S222; No), a process is performed to display the ship as an icon as a non-warning ship on the screen (S226), and the ship is displayed in a non-warning color on the screen. The second fan shape of the ship is displayed (S227), and the caution target ship extraction process ends.

In the above example, the collision prediction function is executed in the communication terminal 200 used by the ship operator 20, but as a modified example, when the operating company 30 monitors the navigation status of its own ship from land, the collision prediction function is executed in the communication terminal 200 used by the ship operator 20. For example, when the insurance company 50 verifies an accident related to a contracted vessel, the collision prediction situation at a specific point in time may be reproduced and displayed. Alternatively, it may be used to present a predicted collision of ships to a manager who controls a congested sea area. Further, in the above example, the warning or cautionary message is displayed as text, but it may be a graphic icon or a voice message.

[3.3 Virtual wireless function]
Next, the virtual wireless function will be explained. The virtual radio in this embodiment is a function that realizes two-way voice communication similar to international VHF specified in SOLAS and ship safety regulations, and is a function that realizes two-way voice communication similar to international VHF specified in SOLAS and ship safety regulations. This makes it possible to perform half-duplex communication on an IP network by using voice processing devices such as microphones and speakers that are standardly provided in the land management terminal 300 and IP communication functions.

[3.3.1 Screen image of virtual wireless function]
FIG. 23 is a diagram showing a screen image that presents virtual wireless functions to the user. When the virtual wireless button B3 on the screen displayed on the communication terminal 200 is pressed, the virtual wireless operation panel TP is displayed. Similar to international VHF, the virtual radio function is a push-to-telephone function in which audio can be transmitted while the person who wants to talk holds down the PTT button Bptt on the radio, and if the PTT button Bptt is not pressed, the system is in standby mode. Calls are made using the Push to Talk (PTT) method. In half-duplex communication, listeners other than the PTT speaker can only speak if they press the PTT button (PTT speaking), and other users can only listen (PTT listening). The user cannot press the PTT button or speak until the speaker releases the PTT button. The status lamp SP indicating the call status on the virtual wireless operation panel TP is displayed in gray in the standby state, but is displayed in green during PTT utterance, and displayed in red during reception.

In addition, in international VHF, channel 16 (156.8MHz) is a common channel exclusively for distress safety and calling, and after calling another ship on this channel, move to another channel and make a direct call. A similar operation is assumed for virtual radio, and by pressing the PTT button after inputting the channel number using the numeric keypad, it becomes possible to transmit and receive audio using the changed channel. The virtual wireless operation panel TP is also provided with a channel 16 button Bc16 for ending the call and moving to a state where channel 16 is listened to.

Displayed on the ship icon are wireless icons indicating the virtual wireless status of the ship equipped with the communication terminal 200 on which the application 220 has been activated, including a wireless icon TI1 indicating a standby status and a wireless icon indicating a call status. TI2 is distinguished by the color of the icon. For example, the wireless icon TI1 indicating the standby state may be displayed in gray, and the wireless icon TI2 indicating the call state may be displayed in green.

International VHF has a maximum output power of 25W and a communication distance of 50 to 80km, but for radios with an output power of 5W, which are mainly used by small vessels, the communication distance is 10 to 30km. It has become. Since virtual radio is communication realized on an IP network, there are no restrictions on output power or communication distance, and calls between remote locations are possible. However, receiving communications from a ship in a remote location that does not affect its own navigation can cause confusion. Therefore, in this embodiment, such confusion is avoided by limiting the virtual radio used for communication between ships to a distance necessary for collision avoidance. The distance required for communication to avoid a collision may be, for example, a radius of 10 km, based on the communication distance of a wireless device with an output power of 5 W.

[3.3.2 Processing related to virtual wireless function]
Processing related to the virtual wireless function will be described below with reference to sequence diagrams shown in FIGS. 24 and 25. FIG. 24 is a sequence diagram showing processing from connection to standby. The virtual radio is realized by connecting the application 220 installed in the communication terminal 200 to the voice server 130 built in the management server 100. The audio server 130 uses the data store 140 to manage the connection status etc. of each application 220. In this embodiment, WebSocket is used as the communication protocol used by the voice server 130 as described above, and Redis, which is an in-memory-based key-value store (KVS), is used as the data store. This speeds up processing. Note that the communication protocol and data storage method are not limited to these.

International VHF channels are specified by frequency, but in this embodiment, they are specified using channel IDs. When the application 220 connects to the audio server 130 (s1101), the application 220 sends the channel ID corresponding to the set channel number along with the location information and time stamp to the audio server 130, and requests participation by the corresponding channel ( s1102). The audio server 130 deletes the registered channel from the data store 140 (s1103). Note that if there is audio being received at this point, the reception is stopped. Next, the currently set channel ID is sent and added along with the location information and the socket ID that identifies the socket connected to the application 220 (s1104), and a time stamp with a deadline set is set (s1105). . After performing this series of processes, the audio server 130 notifies the application 220 of participation using the channel ID (s1106). Although the processing on the application 220 side related to channel setting is omitted in this figure, it is set to channel 16 as an initial state at startup, and the channel ID corresponding to channel 16 is transmitted in step s1102. Thereafter, when the channel is changed based on the operation of the virtual wireless operation panel TP, a channel ID corresponding to the changed channel number is transmitted.

The application 220 continues to update the location information stored in the data store 140 by notifying the audio server 130 of the current location at regular intervals, such as every 10 seconds, for example. More specifically, the channel id, location information, and time stamp are notified from the application 220 (s1107), and the audio server 130 adds the channel id, socket id, and location information to the data store 140 (s1108), A time stamp with a time limit is set (s1109). After performing this series of processes, the audio server 130 responds to the location information notification to the application 220 (s1110). The processes from steps s1107 to s1110 are repeated until the application 220 is terminated (s1111).
Since the timestamp is not updated when the application 220 is terminated, when the audio server 130 recognizes that the timestamp has expired (s1112), it deletes the channel from the data store 140 (s1113) and disconnects the socket connection.

FIG. 25 is a sequence diagram showing processing during a PTT call. In this figure, the application for speaking is 220A, and the application for listening to voice communication is 220B. Although only one application 220B is described, the operation is the same even if there are multiple applications.
When the PTT button Bptt of the application 220A is pressed (s1201), the application 220A notifies the audio server 130 that the PTT button Bptt has been turned on (s1202). At this time, the application 220A notifies the channel ID, location information, radius, and own ship ID. The audio server 130 creates a session room based on the notification (s1203), and sends a notification that it is now possible to speak to the application 220A, including the created session room ID and the ID of the vessel that can speak (s1204). . In response to this, the application 220A changes the status of the status lamp SP and the wireless icon TI to green (s1205), and performs processing to turn on the microphone of the communication terminal 200 (s1206).

The audio server 130 searches the ship information stored in the data store 140 in order to identify the PTT listening side application 220B (s1207). As described above, in this embodiment, since it is possible to make calls to ships located within a radius of 10 km around the speaking ship, the voice server 130 uses the location information and information notified from the application 220A in step s1202. A search range is calculated using the radius, and the data store 140 is searched for the socket ID of the application 220B on the ship that has position information that falls within this range.

The audio server 130 uses the socket ID searched in step s1207 to send a notification to the listening side application 220B that it is now possible to receive a PTT call, including the session room ID and the speaking vessel ID. (s1208). Upon receiving the notification, the application 220B changes the status of the status lamp SP and the wireless icon TI to red, and performs processing to disable the operation of the PTT button Bptt (s1209).

When a PTT call is possible after a series of these processes, audio data is transmitted from the calling side application 220A to the audio server 130 (s1210), and the audio data is broadcast from the audio server 130 to the listening side application 220B. (s1211). Then, the application 220B that has received the audio data reproduces the audio data (s1212), thereby making it possible to listen to the audio call made by the application 220A. To generate voice data, a codec for Voice over Internet Protocol (VoIP) may be used, and known examples include G711, G722, G726, GSM, iLBC, Speex, and Opus. Alternatively, MP3, AAC, WMA, WAV, AC3, FLAC, etc., which are widely used for compressing audio files, may be used.

When the speaking application 220A detects that the PTT button Bptt is released and turned off (s1213), the application 220A sends a notification to the audio server 130 that the PTT is turned off (s1214). ). The audio server 130 that has received this notification broadcasts a notification to end the call to the applications 220 participating in the session room (s1215). The applications 220A and 220B that have received this notification change the states of the status lamp SP and the wireless icon TI to gray, and perform processing to enable the operation of the PTT button Bptt (s1216).

In this embodiment, in addition to phone calls between ship operators 20 using the virtual wireless function on the app 220, the operating company 30 and the construction contractor 40 conduct voice communication with the ship operator 20 using the shore management terminal 300. The group wireless function for this purpose is also realized as one of the virtual wireless functions. Here, FIG. 26 is a screen image of the land management terminal executing the group radio function. In group radio, a unique session room is assigned to a corporate account or project account, so unlike the above-mentioned virtual radio, a panel for specifying channels is not required. Therefore, on the screen of the land management terminal 300, a status lamp SL indicating the group radio call status and a PTT button Bptt are displayed, but a numeric keypad and a channel 16 button Bc16 are not provided. In the example shown in FIG. 26, a map display screen for a certain project is shown, and a list of ships in operation and ship icons are displayed. In the example shown in this figure, by displaying a sailing ship and a stopped patrol ship in different formats, it is easy to visually understand the differences in ship types and roles in the project.

[3.3.3 Processing related to group wireless function]
FIG. 27 is a sequence diagram showing processing related to group radio. In this figure, the PTT speaking side is the application 220, and the PTT listening side is the browser 310. In group radio, a group identification code is used instead of a channel ID, and as the group identification code, for example, a code obtained by hashing a company ID or a project ID is used. The application 220 and the browser 310 notify the audio server 130 of the group identification code and participate in the group radio (s2101). The voice server 130 adds the notified group identification code to the group member list stored in the data store 140 (s2102), and notifies the application 220 and browser 310 that they have participated in the group wireless communication (s2103). ).

In group radio, since the target range for communication is specified in advance, there is no need to consider the communication range based on distance as in the above-mentioned virtual radio. Therefore, when the on state of the PTT button is detected in the application 220 (s2104), only the ship ID is included when transmitting a notification that the PTT is on to the audio server 130 (s2105). In addition, when the browser 310 becomes the PTT utterance side, some kind of ship ID may be assigned to the office on land, or an identifier other than the ship ID may be used.
The series of operations from the process in which the audio server 130 receives the PTT on notification creates a session room (s2106) to the process in which the application 220 turns on the microphone (s2109) is the same as steps s1203 to s1206 described in FIG. 23. , detailed explanation will be omitted.

On the other hand, after the audio server 130 creates a session room (s2106), it searches the data store 140 to obtain a group member list in order to identify the listening app 220 and browser 310 (s2110). The audio server 130 notifies the application 220 and browser 310 specified in this group member list that reception is now possible (s2111). Note that the process (s2119) in which the app 220 and the browser 310 that have received the notification change the status lamp SP and the wireless icon TI to gray after the process (s2112) that the app 220 and the browser 310 perform is explained in FIG. Since these steps are similar to steps s1209 to s1216, detailed explanation will be omitted.

[2.5 Route replay function]
Next, the route replay function will be explained with reference to the route replay animation image shown in FIG. In this figure, three frames are illustrated. Although the frame rate at the time of creating the animation is arbitrary, it may be determined as appropriate depending on the ship speed.

Each frame can be created by referring to the voyage history position table of the database 150 illustrated in FIG. The start and end dates and times of the route reproduction animation may be for the entirety of one voyage, or the start and end dates and times may be specified. Note that the route playback animation may be created each time playback is instructed, or the created animation may be saved as a video file.

Frames FL1, FL2, and FL3 illustrated in FIG. 28 are route reproductions with "Maru X" as the own ship, and "ABCD" is displayed as the other ship. In frame FL1, the courses of the two ships intersect, and if the own ship maintains its course, there is a risk of collision. "X-Maru" looks at "ABCD" to the right (looks at the red port light), so it becomes the give-way ship, and "ABCD" becomes the holding ship. In the FL1 situation, as described with reference to FIG. 19, a warning is given to the vessel operator 20 by the collision prediction function provided by the application 220 on the "X Maru" side. From frame FL2, it can be seen that the operator 20 of "X-maru" who received the warning slowed down and started turning to starboard, and after that, from frame FL3, "X-maru" turned to the port side of "ABCD". It can be seen that the collision could be avoided by passing the vehicle.

On the display screen of the route playback animation, as shown in the display example of frame FL3, a seek bar indicating the playback location may be provided. It may also be displayed together with a mark indicating. Such playback gaze points may be condition settings based on information presented to the vessel operator, such as warning displays or caution displays, or the degree of vessel operation risk determined by a predetermined algorithm regarding the relationship with other vessels. Conditions may be set using functions for post-analysis such as.

[3.4 History output function]
Next, the history output function will be explained. FIG. 29 is a diagram schematically showing the flow from the start to the end of ship maneuvering. The application 220 provides the boat operator 20 with an operation interface for instructing the boat operator to start and end the boat maneuver. In the example shown in FIG. 29, the ship operator 20 is able to select the vessel, the purpose of the ship maneuver, and the role before starting the ship maneuver, and these items are based on the beta base described with reference to FIGS. 8 and 9. As shown in the configuration, the items are normalized and associated, and selectable items are specified in advance.

An operation in which the vessel operator 20 presses the vessel operation start button Bs is transmitted to the management server 100 and passed to the voyage controller 117, which is a function provided by the API server 110. Along with the vessel operator ID, vessel ID, vessel operation purpose ID, role ID, and date and time received from the application 220, the vessel operation start date and time are registered in the vessel operation history table of the database 150. Note that when the ship operator 20 operates a ship as part of the operation of the operator 30, the operator ID is linked to the operator ID and project ID, so the operator ID and project ID are also registered in the ship operation history table. be done.
At the end of the maneuver, when the operator 20 presses the end button Be for maneuvering, the operation is transmitted to the management server 100, and the end date and time of the maneuver is calculated together with the maneuver distance and registered in the database 150.

In this way, for each vessel operator 20, the vessel operation history associated with the vessel operated, the purpose of the vessel operation, and the role can be managed on the database. Regarding personnel onboard patrol vessels and work vessels, there may be cases where it is necessary to manage and submit career information to the port administrator. The ``Guidelines for Deployment, etc.'' requires applicants to also submit their career history as a captain of a patrol vessel, a full-time security personnel, or a security operations manager, as well as the date of the management course taken and the name of the course organizer. In order to maintain a marine license, it is mandatory to manage the boarding history, but since there is no system for managing the history for small vessel operating licenses, such information must be managed on the system as operational status and vessel operation history. By doing so, it becomes easier to manage the career history of ship operators.

Here, FIG. 30 is a display example of a ship operation history of a certain ship operator. In this example, the total number of boat maneuvers, boat maneuvering time, and boat maneuvering distance of 20 individual boat operators is shown, and information for each boat operated is also presented. It is possible to transition to a page that displays a list of ship maneuvering history for each voyage, and in addition to the ship maneuvering date, maneuvering time, and maneuvering distance, gaze points as explained using Fig. 28 are generated as the ship maneuvering history for each voyage. You may also display the number of times you have done so.
Further, FIG. 31 is a display example of the ship operation history in a project, and the voyage history linked to the project is displayed in a list. Each line of the list displays the ship name, purpose of ship operation, operator, role, total time, and total distance.

[3.5 Monitoring area creation function]
[3.5.1 Plot creation screen]
Next, the monitoring area creation function will be explained. FIG. 32 is an example of a plot creation screen for setting a monitoring area. Examples of areas to be monitored include areas where construction work is being carried out, where the deployment of patrol vessels is mandatory, and areas where large-scale oil spills have occurred. In this embodiment, the sea area where the construction work targeted by the project is being carried out is set as a monitoring area, and the patrol vessels to be operated are managed in the project. If a ship that is likely to enter the set monitoring area is detected, a warning is issued to the patrol ship.
The project manager can register the latitude and longitude of the implementation area by specifying multiple points on the map, and after confirming the set area on the screen, press the OK button Bd. Position information consisting of latitude and longitude specified on the screen is registered in the database 150.

[3.5.2 Data structure related to plot creation]
FIG. 33 is a diagram illustrating a data structure regarding position information and ship information registered as a monitoring area. As explained in FIG. 13, the data indicating the latitude and longitude corresponding to a specified point on the map can be obtained from multiple plot IDs linked to plot IDs that have been flagged as having multiple plot points. Managed as a plot point ID.

On the other hand, in this embodiment, the data store 140 referred to by the application 220 used by the vessel operator 20 is a document-oriented non-relational database, and includes a plot ID that specifies a monitoring area, and a warning list placed in the monitoring area. The ship ID and time stamp of the ship are managed as one document.
The data store 140 also has a file for managing ships whose warning areas (see FIG. 17) overlap with the monitoring areas. In the warning area file, a plot ID that specifies a monitoring area, a ship ID whose warning area overlaps with the monitoring area, and a time stamp are managed as one document.

[3.5.3 Warning display example]
FIGS. 34 and 35 are images of screens displayed on the app when a sailing ship approaches a monitoring area. In the example of FIG. 34, "Komaru" is the own ship and is registered in the project as a patrol ship. "Aiumaru" is another ship approaching the monitoring area, and the warning area overlaps with the monitoring area. Additionally, an icon indicating that the virtual radio is in a standby state is displayed. FIG. 32 is an example in which the operator 20 of the "Komaru" who has been alerted by the warning message displayed by the application 220 displays a virtual radio panel in order to encourage communication with the "Aiumaru". The example in FIG. 35 shows an example of a warning displayed to the app 220 on the approaching ship. In this way, it is possible to display a warning through the app 220 and to communicate via virtual radio to a ship that approaches the monitoring area, so it is possible to display a warning through the app 220 and to communicate via virtual radio to a ship that is anchored near the construction area or has already safely evacuated. It is possible to avoid frequent unnecessary warnings such as issuing warnings to ships as well.

[3.5.4 Processing related to monitoring area]
FIG. 36 is a flowchart showing a process for detecting a ship approaching a monitoring area, and this process is executed by the application 220. When the process is started, it is determined whether or not the warning area document including the plot ID set in the monitoring area document including the vessel ID of the own ship is registered in the data store 140 (S301), and whether or not it is registered is determined. If there is a ship (S301; Yes), the warning area of the ship is calculated based on the ship ID in the warning area document (S302). Next, it is determined whether the calculated warning area overlaps with the monitoring area specified by the plot ID and the warning area (S303), and if it is determined that they overlap (S303; Yes), the warning area is shown in FIG. 32 as an example. A warning display as shown above is executed (S304), and the process ends.
If it is determined in step S303 that the monitoring area and the warning area do not overlap (S303; No), the warning area document is deleted from the data store 140 (S305), and the process ends.

If it is determined in step S301 that the warning area document is not registered in the data store 140 (S301; No), the warning area of surrounding ships within a certain range is calculated (S306), and the calculated warning area is calculated. It is determined whether the monitoring area and the warning area, which are specified by the plot ID, overlap (S307). If it is determined that the monitoring area and the warning area overlap (S307; Yes), a warning area document is registered in the data store 140 (S308), and if it is determined that they do not overlap (S307; No), the warning area document is registered in the data store 140 (S308). Processing ends without registering the area document.

Next, FIG. 37 is a flowchart of processing regarding a warning area document. The application 220 in the ship maneuvering status refers to the documents registered in the data store 140, extracts other ships within a certain range from the own ship as explained in FIG. 20, and also monitors the monitoring area document. ing. It is determined whether a warning area document including the own ship's ship ID is registered in the data store 140 (S311), and if it is not registered (S311; No), the monitoring area is registered in the own ship's warning area. It is determined whether or not there exists (S312). When it is determined that the monitoring area exists (S312; Yes), it is determined whether the monitoring area continues for a certain period of time or more and overlaps with the warning area of the own ship (S313). Depending on the course of the own ship, the warning area of the own ship may overlap the monitoring area for only a short period of time, so it is desirable to issue a warning only when the overlap continues for a certain period of time or more.

If it is determined in step S313 that the overlap continues for a certain period of time or more (S313; Yes), a warning area document is registered in the data store 140 (S314), the timestamp is updated (S315), and the process ends. do. If it is determined in step S312 that the monitoring area does not exist within the warning area (S312; No), the process ends without registering the warning area document.

If it is determined in step S311 that a warning area document including the ship ID of own ship is registered (S311; Yes), it is determined whether the warning area has already been removed from the monitoring area (S316). If it is determined that the warning area document is out of the monitoring area (S316; Yes), the warning area document is deleted from the data store 140 (S317), and the process ends. On the other hand, if it is determined in step S316 that the warning area is not out of the monitoring area (S316; No), the time stamp of the warning document is updated (S315).

In the above example, when a ship approaching the monitoring area is detected, a warning is displayed on the patrol boat's app 220, but if it is used for fishing, for example, as illustrated in FIG. 38, It is also possible to display a warning on the browser 310 used by the onshore administrator. The example in this figure shows a mode in which a warning is displayed to a land-based observer when a ship approaches a fixed net plotted as a monitoring area.

[4 Configuration for offline operation]
The above example assumes that the communication terminal 200 is within the communication range of the carrier network CN or private network PN, but at sea, communication may become unstable depending on the distance from the base station, the surrounding radio wave environment, etc. communication may be interrupted. Further, since it is thought that satellite data communication is rarely used in mobile phones or tablets used by general users, it is assumed that the communication terminal 200 may sail in an ocean area where the management server 100 cannot be accessed.
Therefore, in this embodiment, even in an environment where the communication condition is not good and the communication terminal 200 cannot access the management server 100, the AIS radio waves emitted by surrounding ships can be received, and the application 220 alone can receive the AIS radio waves from the ship along with its own position. It also has a feature that displays the map and predicts collisions.

As described using FIG. 4, the marine AIS receiving device 900 has a function of receiving AIS signals emitted by surrounding ships in the VHF band and transmitting them in BLE. The application 220 can perform map display and collision prediction based on the AIS ship position data received from the reception/transmission program 901 and own ship position data generated by the positioning program 210.

Furthermore, since the information providing server 700 cannot be accessed outside the communication range of the wireless network, the map data 710 is also used offline, but the map is displayed using the map data cached in the memory of the communication terminal 200. It is configured so that it can be done.
In the above example, a configuration using BLE was explained for the connection between the communication terminal 200 and the maritime AIS receiving device 900. Wireless communication using another unlicensed band may be used, or a configuration may be used in which connection is made by wired communication such as Ethernet (registered trademark).

[5 Effects of embodiment]
As described above, according to the ship movement sharing navigation support system according to the present embodiment, the map screen that presents the movements of the own ship and other ships in the vicinity to the ship operator has a user interface that is easy to understand intuitively. The system is configured to facilitate voice communication between system users. Furthermore, since there is no need to obtain a license for radio use or to open a radio station, the system can be easily disseminated to non-SOLAS ships that are not required to be equipped with AIS or international VHF.

The ship movement sharing navigation support system can be used as a platform for managing ship movement information and ship operator information, and wide use will be facilitated by publishing the API.
In sea areas where communication conditions are unstable, by locally connecting the maritime AIS receiver 900 and the communication terminal 200, it is possible to grasp the movements of surrounding AIS ships, and display the map using map data cached in the communication terminal 200. Since the functions are provided, it becomes possible to respond to changes in the communication environment.

In addition, for ships that wish not to publish their own position, the system is equipped with a function that displays only the movements of ships that are generally visible and located at a distance necessary for collision prediction, ensuring anonymity and safety. This makes it possible to achieve both, making it easy to promote the use of the system for non-SOLAS vessels such as fishing boats and pleasure boats.

The sea area where construction work is being carried out can be plotted as a monitoring area, and it is possible to monitor the movements of ships approaching the monitoring area and issue warnings to such ships and patrol boats. It is possible to improve safety and convenience during construction work. Further, the functions related to the setting of monitoring areas and warnings are highly convenient for port administrators and fishermen.

In addition, since the database manages history by linking ship operator and vessel information, it can also be used for boarding history of patrol boat crews, calculation of insurance premium rates, etc. Since the navigation history can be played back as an animation, it can also be used for post-mortem verification in the event of an accident, and for analyzing trends in judgment by ship operators and trends in the occurrence of collisions. If ship operation history is used for career advancement of ship operators and preferential treatment for insurance, it will be easy to promote the spread of ship movement shared navigation support systems for non-SOLAS ships.
Therefore, functions useful for ship collision prevention can be presented to more ship operators in a manner that is easier to understand.
Note that the embodiments described above disclose at least the configurations described below.
(1)
a database that manages at least vessel operator identification information for identifying a vessel operator, vessel identification information for identifying a vessel, and vessel movement information history indicating the position and movement of the vessel;
a backend service that receives ship position data indicating at least position information of a ship and stores it in the database;
a backend platform including;
a front end that receives data output to the user interface and operation input from the user;
an application programming interface (API) that is an interface between the back end platform and the front end;
Equipped with
The user interface displays ship movement shared data converted into a format specified by map data based on the ship movement information managed in the database,
The API allows input to link the ship identification information of a ship equipped with a communication terminal that executes an application that provides the user interface with the ship operator identification information of a ship operator who operates the ship, to the user interface. Accepted from
The backend service is a ship movement sharing navigation support system that associates the ship identification information, the ship operator identification information, and the ship movement information and stores them in the database as the ship movement information history.
(2)
The backend platform further includes a data store that stores current values of the ship movement information,
The backend service stores the latest information on the vessel movement information in the data store,
the front end causes the vessel movement information stored in the data store to be displayed on the user interface;
The vessel movement sharing navigation support system described in (1).
(3)
The vessel identification information includes vessel size and vessel type;
A ship icon indicating a ship displayed on the user interface as the ship movement shared data has an image design according to the ship type, and a scale of the ship size corresponds to a scale of the map data.
The ship movement sharing navigation support system described in (1) or (2).
(4)
The ship movement information history includes date and time information, position information, ship speed information, and course information,
The user interface executes ship collision prediction based on a collision prediction area calculated based on the position information, the ship speed information, and the course information, and displays a warning based on the collision prediction.
(1) The vessel movement sharing navigation support system according to any one of 1 to (3).
(5)
The collision prediction area includes a warning area that prompts a warning and a caution area that urges caution,
The warning area is calculated based on the course information and ship speed information and is presented as an area where the ship is likely to navigate within a predetermined time,
The caution area is calculated based on the course information and ship speed information and is presented as an area in which caution should be taken regarding avoidance maneuvers of other ships.
The vessel movement sharing navigation support system described in (4).
(6)
The database further manages plot information including at least position information,
The API accepts input and output of the plot information from the user interface,
The user interface displays plot data corresponding to the plot information managed in the database together with the vessel movement shared data.
The vessel movement sharing navigation support system according to any one of (1) to (5).
(7)
The plot data means a monitoring area that is a monitoring target regarding the approach of a ship,
The user interface prompts a warning when the warning area overlaps the monitoring area.
The vessel movement sharing navigation support system described in (6).
(8)
The backend further includes a voice server that provides voice call functionality via a communication protocol operating at an application layer;
The user interface displays a radio panel imitating a ship radio operation interface,
The audio server controls transmission and reception of audio data to and from the plurality of user interfaces based on the operational input on the wireless panel and the ship information linked to an application that provides the user interface.
The ship movement sharing navigation support system according to any one of (1) to (7).
(9)
The voice server is configured to transmit a predetermined message from the ship linked to the application on the speaking side based on the ship movement information history linked to the ship information when an operation on the speaking side is detected on the wireless panel. specifying the application linked to a ship located within range as a listening side and controlling the transmission and reception of audio data;
The vessel movement sharing navigation support system described in (8).
(10)
The database further manages group identification information that identifies the affiliation linked to the vessel operator identification information and the vessel identification information as a group,
When an operation on the speaking side is detected on the wireless panel, the audio server identifies the application belonging to the same group as the listening side based on the group identification information linked to the speaking side application. to control the transmission and reception of audio data.
The vessel movement sharing navigation support system described in (8).
(11)
The API transmits data for creating a vessel operation history for each vessel operator and a voyage history for each vessel based on the vessel operator identification information, the vessel identification information, and vessel movement information history managed in the database. Provided to the front service,
The front service displays the created ship operation history and navigation history on the user interface.
The vessel movement sharing navigation support system according to any one of (1) to (10).

100... Management server, 110... API server, 120... Web server, 130... Audio server, 140... Data store, 150... Database, 160... Back-end service, 170... AIS reception server, 200... Communication terminal, 210... Positioning program , 220... Application, 300... Land management terminal, 310... Browser, 700... Information providing server, 710... Map data, 810... Land AIS receiving device, 811... Receiving and transmitting program, 900... Maritime AIS receiving device, 901... Receiving and transmitting program.

Claims (11)

a database that manages at least vessel operator identification information for identifying a vessel operator, vessel identification information for identifying a vessel, and vessel movement information history indicating the position and movement of the vessel;
a backend service that receives ship position data indicating at least position information of a ship and stores it in the database;
a backend platform including;
a front end that receives data output to the user interface and operation input from the user;
an application programming interface (API) that is an interface between the back end platform and the front end;
Equipped with
The user interface displays ship movement shared data converted into a format specified by map data based on the ship movement information managed in the database,
The API allows input to link the ship identification information of a ship equipped with a communication terminal that executes an application that provides the user interface with the ship operator identification information of a ship operator who operates the ship, to the user interface. Accepted from
The back-end service associates the ship identification information and the ship operator identification information with the ship movement information and stores it in the database as the ship movement information history,
The backend further includes a voice server that provides voice call functionality via a communication protocol operating at an application layer;
the user interface displays a wireless panel;
The audio server controls transmission and reception of audio data to and from a plurality of user interfaces based on operation input on the wireless panel and the ship information linked to an application that provides the user interface, and is configured to share ship movement. Navigation aid system. The backend platform further includes a data store that stores current values of the ship movement information,
The backend service stores the latest information on the vessel movement information in the data store,
the front end causes the vessel movement information stored in the data store to be displayed on the user interface;
The vessel movement sharing navigation support system according to claim 1. The vessel identification information includes vessel size and vessel type;
A ship icon indicating a ship displayed on the user interface as the ship movement shared data has an image design according to the ship type, and a scale of the ship size corresponds to a scale of the map data.
The vessel movement sharing navigation support system according to claim 1 or 2. The ship movement information history includes date and time information, position information, ship speed information, and course information,
The user interface executes ship collision prediction based on a collision prediction area calculated based on the position information, the ship speed information, and the course information, and displays a warning based on the collision prediction.
A vessel movement sharing navigation support system according to any one of claims 1 to 3. The collision prediction area includes a warning area that prompts a warning and a caution area that urges caution,
The warning area is calculated based on the course information and ship speed information and is presented as an area where the ship is likely to navigate within a predetermined time,
The caution area is calculated based on the course information and ship speed information and is presented as an area in which caution should be taken regarding avoidance maneuvers of other ships.
The vessel movement sharing navigation support system according to claim 4. The database further manages plot information including at least position information,
The API accepts input and output of the plot information from the user interface,
The user interface displays plot data corresponding to the plot information managed in the database together with the vessel movement shared data.
A ship movement sharing navigation support system according to any one of claims 1 to 5. The plot data means a monitoring area that is a monitoring target regarding the approach of a ship,
The user interface prompts a warning when the warning area overlaps the monitoring area.
The vessel movement sharing navigation support system according to claim 6 , which refers to claim 5 . 8. The vessel movement sharing navigation support system according to any one of claims 1 to 7, wherein the radio panel imitates an operation interface of a vessel radio. The voice server is configured to transmit a predetermined message from the ship linked to the application on the speaking side based on the ship movement information history linked to the ship information when an operation on the speaking side is detected on the wireless panel. specifying the application linked to a ship located within range as a listening side and controlling the transmission and reception of audio data;
A vessel movement sharing navigation support system according to any one of claims 1 to 8 . The database further manages group identification information that identifies the affiliation linked to the vessel operator identification information and the vessel identification information as a group,
When an operation on the speaking side is detected on the wireless panel, the audio server identifies the application belonging to the same group as the listening side based on the group identification information linked to the speaking side application. to control the transmission and reception of audio data.
A vessel movement sharing navigation support system according to any one of claims 1 to 8 . The API transmits data for creating a vessel operation history for each vessel operator and a voyage history for each vessel based on the vessel operator identification information, the vessel identification information, and vessel movement information history managed in the database. provide it to the front end ,
The front end displays the created vessel maneuvering history and navigation history on the user interface.
A vessel movement sharing navigation support system according to any one of claims 1 to 10.

Images