BE1023097B1 - SOFTWARE FOR ACCESSING AND OFFERING NAUTICAL SENSOR DATA TO SIMPLY ACTIVE WINDOWS APPLICATIONS WITHIN A NETWORK - Google Patents

Abstract

There are a number of problems in the classic approach of linking nautical sensors (GPS receivers, AlS transponders, wind gauges, depth gauges, ...) to software applications. These problems are related to the splitting of the sensor signals and the electrical connection of these sensors to the computers running the applications. The invention described here offers an elegant software solution for distributing sensor data to Windows applications. Sensors can be connected to the nearest computer - possibly distributed over a network. Via a software service, the computer that is connected to one or more sensors will communicate this sensor data to and from (possibly several) applications. A monitor function is provided to view the (status of the) data communication. This solution proves ideal for inland vessels with navigation applications that want to communicate with multiple marine sensors using the serial NMEA protocol.

Description

SOFTWARE FOR ACCESSING AND OFFERING NAUTICAL SENSOR DATA TO SIMPLY ACTIVE WINDOWS APPLICATIONS WITHIN A

NETWORK

TECHNICAL FIELD OF THE INVENTION

Inland navigation vessels make frequent use of navigation systems whose software is executed on a personal computer (PC). Various ship sensors are connected to this navigation computer. Communication with these sensors is mainly via the nautical NMEA 0183 protocol. This is a serial protocol that can be offered by PCs via an RS232 or USB port. GPS receivers, AIS transponders, wind and depth gauges are examples of NMEA 0183-compatible sensors that exist on board.

As mentioned herein, NMEA 0183 stands for "National Marine Electronics Association, standard 0183"; GPS stands for Global Positioning System, the American satellite positioning system and AIS stands for Automatic Identification System, a technology that allows shipping to see each other's position, course and speed in a radius of 30 km.

Software-technical, an application must first 'open' a communication port on its own PC before data can be sent back and forth. Of course it is useful and often essential that several (navigation) applications can communicate with a sensor at the same time. However, current operating systems link this data channel exclusively to the application that first opened the port after 'opening' a communication port. This makes it impossible for another application to open this port and subsequently communicate with the same sensor.

In addition to the described problems of allowing multiple applications on one particular PC to open the same port, it would also be useful that applications on other PCs in a network (LAN (local area network), WAN (wide area network) or the internet) also could gain access to that port. This type of access to a sensor seems to the (remote) application as if it is an access to a local communication port, while the data communication is transparent - across the network. Therefore, multiple applications on different PCs should also be able to share and use ports with each other.

The invention described here provides a solution for both problems: "port sharing" allows applications to share a single port, and by using internet protocol sockets, applications can access ports (on other network PCs) remotely.

BACKGROUND ART

Because it is often practically necessary to offer sensor data to multiple applications, the following options (detours) have so far been used to solve the previously mentioned problems:

Option 1: install multiple PCs with each PC running only one (sensor) application

Disadvantages: • the cost price increases due to the purchase of additional PCs and communication ports; • the cost price increases due to the installation of the additional PCs and communication ports; • the ports are not accessible over a network; • the different applications do not know about each other's existence.

Option 2: electrically split the sensor signals to multiple communication ports where each application can then open its own port

Disadvantages: • the cost price increases due to the installation of the gates and the split cables; • the cost price increases due to the purchase of any additional physical communication ports; • the ports are not accessible over a network; • the different applications - which communicate with the same sensor - do not know each other's existence.

With both options, this latter disadvantage mainly causes problems with synchronization with a bidirectional link between a software application and a sensor: if both applications simultaneously send information, the serial signal becomes unreadable for the sensor. As a result, NO or ERROR data arrives at the sensor.

Option 3: install third party splitter software, eg the Eltima Serial Port Splitter product, for duplication of physical communication ports to virtual (software) communication ports

Disadvantages: • the cost price increases due to installation and the purchase of external software; • configuration wise the installation becomes more difficult; • additional third party software is required to make the ports accessible over a network; • The different applications - which communicate with the same sensor - do not know each other's existence because this software simulates ports. The application has no sense of the redirection that occurs externally through this software. As a result, the application cannot respond to this either.

DESCRIPTION OF THE INVENTION

Object of the invention

The purpose of the solution is multiple: • avoid the exclusive allocation of one port to one application; • make ports on a network 'available' for all computers within their network; • use software that is easy to install; • ensure that applications are aware of port sharing (application awareness); and • look for the most cost-effective solution (i.e. no obligation to purchase additional hardware or third party software).

The invention proposed here meets all these requirements. No additional hardware or hardware installation is required. The communication to the sensor is serialized, which means that corrupted data can no longer occur. The applications know each other's existence and can therefore adjust their logic ('software intelligence') accordingly.

The solution described here consists of an additional, new software layer that is placed between the physical communication ports and the software applications. This layer will therefore manage all communication between (multiple) ports and (multiple) applications. We call the software layer of this invention the "communication service" and we call this software service "CommServer" for short.

If desired, the CommServer software can be installed automatically when installing a (CommServer-compatible) application.

Description of the solution

The CommServer is a software service that works with the existing Windows operating system. Any computer (within the network) that wants to open communication ports for CommServer applications will have to start this service. Applications can access ports on the local PC or on a PC within the network (LAN, WAN or internet).

The diagram in FIG. 1 shows the different layers of the total software model on one computer: • At the top are the software applications (red); • The physical connections (purple) to the various sensors are located at the bottom.

The yellow block "Tresco CommServer" represents the invention. It is this software layer that will open the necessary ports exclusively.

After this, application A, B and / or C can access the same sensors by using a socket connection with the CommServer. Thanks to this technique, applications A, B and C can share their communication ports with each other, and, on other PCs, applications can also access these (purple) ports remotely.

However, this approach does not exclude that legacy applications can still open other local communication ports in the traditional way (but only exclusively).

Below is an example scenario, such as in FIG. 2, of a possible link between applications and communication ports for a situation on board a barge with four simultaneously active applications on the bridge: • application A (map navigation) opens the GPS receiver, the AIS transponder and the depth sounder; • application B (radar overlay) opens the GPS receiver and the AIS transponder; • application C (connection screen) opens the GPS receiver and the depth gauge; • application D (loading application) opens (exclusively) the loading sensors.

It is only thanks to the CommServer, see Fig. 2, that applications A, B and C can 'share' their sensors.

Description of the sub-functions and the algorithm

Here you will find a step-by-step description of the CommServer algorithm. Of course, a number of configuration parameters can be set a priori. These configuration parameters are described in a configuration register, whether or not secured via a USB security key or hardware dongle. The register can be stored locally or on a shared network path.

The following parameters are required to be configured a priori for each computer that wants to unlock ports: • the list of which port numbers are to be shared / opened; • the maximum number of applications that each port can access; • IP port numbers on which the CommServer can be reached by the applications via the Windows socket interface (WinSock).

Overview of the CommServer code: • when starting this CommServer, check whether another instance of the CommServer is already active: - if another C / S is active: terminate this instance immediately; - if no other C / S is active: continue with the start-up procedure. • when starting the CommServer code, all configured communication ports are opened exclusively via the standard Windows communication API. API stands for

Application Programming Interface, this is the way in which a software developer can address a software service. • the service starts a TCP / IP listener on the pre-configured internet port number. TCP / IP stands for

Transmission Control Protocol of the Internet Protocol and a listener is a code that is waiting for a request from another application on a certain internet port. • the service waits for incoming applications from applications • for each incoming port request, the CommServer checks whether the maximum configured number of connections is not exceeded - if the maximum is not exceeded: allow the new connection - if the maximum is exceeded: ignore the current connection request • the CommServer now 'listens' to all incoming (serial) data from both the sensors (via the communication ports) and to the incoming (serial) data from the permitted connections of the applications. • the received incoming data is collected in temporary memory buffers • the received data packet is copied from the temporary buffer to a packet buffer • do the following for each opened communication port: send the data packet coming from that particular communication port to all applications that have a connection for this entered into • for each application connection: send the data packet that comes from that particular application connection to the port for which this application previously requested the connection - by - as described above - constantly iterating over: o all configured communication ports, and, o all application connections, all data is automatically serialized and sent correctly one after the other in the correct order. Damaged data can therefore not occur. • when an application terminates its connection (or 'closes'), the CommServer will terminate this connection • if all application connections are closed, the service will remain active • the CommServer will give all connected applications a keep-alive or heartbeat every 5 seconds package that informs the application that its communication is still active; this is especially important for remote applications

Furthermore, a computer user - for checking the total data communication - can consult a CommServer status window to view the connections and communication (monitor function), see Fig. 3 and FIG. 4.

The described solution applied with a network example

In addition to the example, FIG. 1, which has already been given in the description of this invention, we give a more extensive example in FIG. 5. Here we outline a scenario in which two computers are connected via a (possibly wireless) network.

All 'shared' serial communication ports (being COM1, 2 and 3 from PC 1 and COM1, 2, 3 and 4 from PC 2) are available via the network for both network computers. Of course, the configuration register must initially be configured per computer in this way. With the very first request to connect a CommServer application, the CommServer will be started automatically and unlock all ports via a socket interface.

The term "network" can be interpreted broadly. This can be: an ethernet connection between two computers (LAN), a wireless connection (Wi-Fi) or a long-distance connection (WAN + VPN) via the public internet.

Claims (5)

CONCLUSIONS 1. A method that allows serial (NMEA) data, typical of nautical NMEA 0183 sensors on board ships, and received via one or more PC communication ports, to be distributed or distributed over multiple (Windows) applications by the manage connections (communication ports) via a generic socket interface. 2. A method that allows serial (NMEA) data, typical for nautical NMEA 0183 sensors on board ships, and received via one or more (Windows) applications, to be transmitted to a physical PC communication port, through the connections ( communication ports) via a generic socket interface. 3. A software instrument capable of quickly, safely and smoothly spreading the typical shipping sensor data over a network on ships' bridges executing multiple (Windows) applications simultaneously on board of ships, using the methods of claim 1 and / or 2. Use of the methods of claim 1 and / or 2, so that the applications ((Windows) applications) know implicitly that they can communicate data via this interface so that they can exchange data more intelligently with sensors. A computer program that has been running on all Microsoft operating systems since Windows 2000, which contains the algorithm for managing the connections (communication ports) via a generic socket interface, suitable for the methods of claim 1 and / or 2.