The Hoppe Ship-to-Shore connection does not provide any own VSAT connection. Therefore the client must ensure to have a VSAT connection available. For the communication with the land-based servers, the following IP addresses on the corresponding port for outgoing TCP data traffic of HOMIP2 must be enabled in the vessels firewall.

Primary Address – IP: 75.2.111.192 – Port: 11550
Fallback Address – IP: 99.83.166.216 – Port: 11550

A detailed checklist will be provided upon request.

In terms of data storage, Hoppe Marine utilizes the structure of a “Data-Lake”. It is based on a concept in which structured data can be loaded into the data pool from a variable source. In this term structured data means e.g. log data, telemetry data etc. In the field of data analysis, time series data in various formats are the most relevant data. Currently, the following formats are accepted: CSV, JSON, SQLite and Parquet. Furthermore, it is important that the client defines the column name-assignments, due to the fact that for evaluation the data must be set to a universal naming standard.

Data transmission is based on packages, their content is irrelevant. The only important thing is, that all packages need to be cryptographically signed prior to transmission to give proper evidence regarding their source. Therefore Hoppe Marine offers a crypto-software-solution on HOMIP units, capable of signing data of various sources. In this case a REST API enables access to this feature.

Currently, this feature is available only for Hoppe-internal services. The release of the interface for data transmission of external partners is part of our release plan 2021.

However, the embeddded iPC HOMIP supports several protocols for data collection. with the iDBS database solution Hoppe Marine offers a feature to make use of interfaces of other manufacturers to store the data and to make it available on shore side. This feature is available right after activation of the service.

The Ship-to-Shore transmission utilizes a multi-level safety concept. This concept distinguishes between Identity Protection, Access Protection and Integrity Protection.

Identity Protection

The first level of the safety concept ensures trustworthiness of the communication partners. Thereby every end point of communication is fitted ex works with a private, cryptographic key. This key never leaves the device and cannot be compromised therefore. Only when a correct key is known the device gets enabled to transmit or receive data.

Access Protection

When it is ensured that data comes from a trustworthy source, a secure SSL-encrypted connection between the communication partners will be established in the next step. This encrypted connection prevents access from third parties, only both communication partners are able to read the data in clear format.

Integrity Protection

After successful transmission of data a further step is implemented to ensure the data is intact and corresponds to the data that has been sent from the vessel. Therefore cryptographic signatures according the industrial standard RFC 7519 are used.

Our provider, responsible for data storage, is certified according to ISO/IEC 27001:2013. The certification guarantees the following core concepts of a data storage provider in terms of data protection and security:

We evaluate our IT-safety risks systematically considering the effects of threats and weaknesses.
We design and we follow a complete range of IT-security checks and other forms of risk management to manage all safety risks of company and architecture.
We introduce a complete management process to assure that our IT-security checks meet our ITsafety procedures at all times.
Accessing the data is permitted based on the so called Least-Privilege model. The access to every resource must be actively granted by Hoppe administrators, before a new user can have access to data. The access to data can be defined very detailed and tailored:

In general, for every user the access to specific vessels can be determined in details.
Furthermore, it can be determined individually or for every user whether one can have a look on raw data, or just have access to aggregated data.
Generally, the data access is only possible via a few but highly monitored channels. This eases an early detection of unauthorized access.

During transport the data is encrypted via TLS from the endpoint on the ship to the endpoint in the cloud solution and during all transport inside the clouds private network. Additionally the payload data is signed with a cryptographic key (EC-512) to eliminate any chance of data manipulation in transit. Hardware on the ship needs to prove it’s identity before a connection can be established to shore. This identity management is based on EC-512 certificates. Trust is established by exchanging the public keys of the device with the shore side server during device production.

All data is protected against loss by six backup copies. Furthermore data is stored in at least two different server centres within the European Union (EU) to assure data security and data integrity even in natural disasters, like fire. In terms of constant, worldwide accessibility, the provider of the infrastructure guarantees an availability of 99.47%. For the worst case in terms of daily data transmission, this means that the access to data can only be not granted for maximum two days per year. In terms of data storage it can be assured at all times that data can be stored and catalogued appropriately and that no data gaps occur.

For data storage Hoppe Marine utilizes a model called WORMS. With WORMS all data, that has been stored once in the data pool, cannot be changed any more. This ensures that all data can neither be overwritten nor be deleted. Furthermore, each data is protected against any loss by six backup copies. And in addition to that, all data is stored in at least two different server centres within the European Union (EU) to ensure data protection and data integrity even in natural disasters, like fire.

The chosen IT-infrastructure is designed for good horizontal scaling. This means, that during higher data volume the service resources get enhanced accordingly. Therefore a transmission of 1000 data points per minute is no problem, as long as the satellite connection offers the required bandwidth.

Upload from the shore side to the ship is only possible in a specific package format. The corresponding API endpoints are secured by two measures: user authentication as well as IP based whitelisting. No ingress connection can be initiated from the outside towards the ship. Only the ship can establish a connection to two fixed unicast IP addresses. No DNS resolution is involved in the process. Only approved service engineers can upload and install updates for the device on the ship and change connection parameters, but have never direct remote access (e.g. via SSH or any remote shell) to it. Only cryptographically signed update packages are accepted by the devices on the ship. The cryptographic material for signing is managed in a HashiCorp Vault implementation.

The data transmission is file-based. The interval for data exports can be configured. For data transmission a satellite connection is established and for transmitting the data, a direct, encrypted connection to fixed IP addresses without DNS is realized. All files are collected as database files and transmitted together in blocks. By using the Hash-method, the entire file content is subject to an integrity test. The transmission of encrypted data underlies a bandwidth regulation.

Encryption, connection set-up, etc. have been optimized already. However, one should always consider the following: The smaller the single exported data blocks are (i.e. the shorter the export intervals are), the bigger the relative overhead is. This can be seen similar to a letter that is always 80ct., no matter if it is one A4 page or three A4 pages. The following image indicates the measuring results of the interrelation between payload size and transmission overhead. It is well indicated that the relative overhead becomes smaller in case of encryption and transmission of bigger file sizes.

Yes. But this case only happens to files where the transmission cannot be continued. In the „normal“ case of a connection failure, the transmission will continue where it got interrupted. Only in case of a high amount of package-losses, the transmission will be repeated completely. A bandwidth detection prevents any transmission, in case the risk of a weak transmission is detected. Therefore, the complete repetition of a transmission is only the last resort. The maximum amount of transmission attempts can be determined per file. Thus, expensive and endless attempts are avoided. When a better connection quality is detected, the transmission can be restarted via a web interface directly on board.

The time series data is logged by Hoppe Marines iDB server, which uses the master time on the HOMIP2 as the time source. This time source is configured on the HOMIP2 display and is independent of the date/time of the operating system. If the customer has a GPS receiver on board, the HOMIP2 can also use the GPS time signals as the time source. GPS time signals are preferred as time source, since they provide a well established times standard. Additionally, chances to enter the date/time incorrectly are minimized.

Our goal is to log and provide ship operation data accurately and consistently. This allows in retrospective to identify the exact date and time at which an event occurred or what the signal value was at that moment. This cannot be done if the time source is not reliable. As a worst case example, if the time has changed back, duplicate data can occur for the same given time range. If this occurs, meaningful report can not be generated.