EP4685044A2 - Militärisches wasserfahrzeug mit sensoren - Google Patents

Militärisches wasserfahrzeug mit sensoren

Info

Publication number
EP4685044A2
EP4685044A2 EP25214488.6A EP25214488A EP4685044A2 EP 4685044 A2 EP4685044 A2 EP 4685044A2 EP 25214488 A EP25214488 A EP 25214488A EP 4685044 A2 EP4685044 A2 EP 4685044A2
Authority
EP
European Patent Office
Prior art keywords
analysis
watercraft
database
data
computers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP25214488.6A
Other languages
English (en)
French (fr)
Other versions
EP4685044A3 (de
Inventor
Bastian Ebeling
Axel Rasch
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tkms GmbH
ThyssenKrupp AG
Original Assignee
Tkms GmbH
ThyssenKrupp AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tkms GmbH, ThyssenKrupp AG filed Critical Tkms GmbH
Publication of EP4685044A2 publication Critical patent/EP4685044A2/de
Publication of EP4685044A3 publication Critical patent/EP4685044A3/de
Pending legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B63—SHIPS OR OTHER WATERBORNE VESSELS; RELATED EQUIPMENT
    • B63B—SHIPS OR OTHER WATERBORNE VESSELS; EQUIPMENT FOR SHIPPING 
    • B63B79/00—Monitoring properties or operating parameters of vessels in operation
    • B63B79/10—Monitoring properties or operating parameters of vessels in operation using sensors, e.g. pressure sensors, strain gauges or accelerometers
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B63—SHIPS OR OTHER WATERBORNE VESSELS; RELATED EQUIPMENT
    • B63B—SHIPS OR OTHER WATERBORNE VESSELS; EQUIPMENT FOR SHIPPING 
    • B63B79/00—Monitoring properties or operating parameters of vessels in operation
    • B63B79/10—Monitoring properties or operating parameters of vessels in operation using sensors, e.g. pressure sensors, strain gauges or accelerometers
    • B63B79/15—Monitoring properties or operating parameters of vessels in operation using sensors, e.g. pressure sensors, strain gauges or accelerometers for monitoring environmental variables, e.g. wave height or weather data
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B63—SHIPS OR OTHER WATERBORNE VESSELS; RELATED EQUIPMENT
    • B63B—SHIPS OR OTHER WATERBORNE VESSELS; EQUIPMENT FOR SHIPPING 
    • B63B79/00—Monitoring properties or operating parameters of vessels in operation
    • B63B79/20—Monitoring properties or operating parameters of vessels in operation using models or simulation, e.g. statistical models or stochastic models
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B63—SHIPS OR OTHER WATERBORNE VESSELS; RELATED EQUIPMENT
    • B63B—SHIPS OR OTHER WATERBORNE VESSELS; EQUIPMENT FOR SHIPPING 
    • B63B79/00—Monitoring properties or operating parameters of vessels in operation
    • B63B79/30—Monitoring properties or operating parameters of vessels in operation for diagnosing, testing or predicting the integrity or performance of vessels
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B63—SHIPS OR OTHER WATERBORNE VESSELS; RELATED EQUIPMENT
    • B63B—SHIPS OR OTHER WATERBORNE VESSELS; EQUIPMENT FOR SHIPPING 
    • B63B79/00—Monitoring properties or operating parameters of vessels in operation
    • B63B79/40—Monitoring properties or operating parameters of vessels in operation for controlling the operation of vessels, e.g. monitoring their speed, routing or maintenance schedules
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B63—SHIPS OR OTHER WATERBORNE VESSELS; RELATED EQUIPMENT
    • B63G—OFFENSIVE OR DEFENSIVE ARRANGEMENTS ON VESSELS; MINE-LAYING; MINE-SWEEPING; SUBMARINES; AIRCRAFT CARRIERS
    • B63G1/00—Arrangements of guns or missile launchers; Vessels characterised thereby
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B63—SHIPS OR OTHER WATERBORNE VESSELS; RELATED EQUIPMENT
    • B63G—OFFENSIVE OR DEFENSIVE ARRANGEMENTS ON VESSELS; MINE-LAYING; MINE-SWEEPING; SUBMARINES; AIRCRAFT CARRIERS
    • B63G13/00—Other offensive or defensive arrangements on vessels; Vessels characterised thereby
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B63—SHIPS OR OTHER WATERBORNE VESSELS; RELATED EQUIPMENT
    • B63B—SHIPS OR OTHER WATERBORNE VESSELS; EQUIPMENT FOR SHIPPING 
    • B63B35/00—Vessels or similar floating structures specially adapted for specific purposes and not otherwise provided for

Definitions

  • the invention relates to a military watercraft, in particular a military watercraft with sensors for recording measured values.
  • Military watercraft are often highly complex systems designed for specific missions and comprise a multitude of components, sometimes from different manufacturers. Compared to civilian watercraft, military watercraft are often characterized by a relatively small production run, high complexity, a large number of components, and a high need to protect vehicle-related data. The composition of the components is therefore often very heterogeneous, and given the sheer number and integration density of components and manufacturers, it is not always possible to comprehensively test the interaction of the individual components for every conceivable operational scenario. Furthermore, manufacturers of vehicle components tend to keep measurement data collected by internal sensors secret to prevent third parties from using this information to replicate or "hack" the components.
  • German patent application DE 102008025803 A1 This describes a marine internal combustion engine with a control device for controlling and/or regulating the operation of the marine internal combustion engine. Based on the ship's position, the control device determines target operating parameters for the marine internal combustion engine.
  • the German patent application DE 102011 086355 A1 Describes a weapon system for object defense, particularly for use on merchant ships, comprising: at least one gun, a firing mechanism, a sensor system for acquiring data, especially environmental and/or target data, and an authorization system.
  • the authorization system is configured to enable or disable the firing mechanism depending on the receipt of a release signal.
  • the German patent application DE 31 50 895 A Figure 1 describes a warship with systems connected via electronic control units.
  • the warship, with its controlling and controlled systems is equipped with electronic control units that generate control signals for the respective controlled systems from raw information received from the assigned controlling system.
  • the electronic control units For each assigned controlled system, the electronic control units have a correction stage for modifying the generated control signals depending on a bedding error of the respective controlled system and/or the controlling system acting on the control unit.
  • memory is provided for storing the bedding error values as a function of the horizontal angular position of the controlled system and/or the controlling system.
  • the US patent application US2018/0304969A1 describes a ship with a propeller mounted on a rotating shaft and a method for converting the Power of a rotating shaft in thrust to propel the ship across the water.
  • the procedure includes obtaining measurements descriptive of the shaft power, estimating two excess shaft powers caused by fouling of the propeller and by fouling of the ship's hull, and issuing a recommendation for propeller cleaning and/or hull cleaning depending on the estimated excess shaft powers.
  • US patent application US2019/0176945A1 describes a movement control system for a ship in a way that optimally balances performance and noise emission.
  • the US patent application US 2006 / 0 058 929 A1 describes a method for verifying a ship's control system in which the control system, in its operating state, receives sensor signals from sensors and sends control signals to actuators in response to maintain a desired position, speed, course, or other.
  • the US patent application US 2018 / 0 356 826 A1 This describes a system and procedure for facilitating decision-making on a watercraft.
  • the procedure includes: collecting environmental data of the environment in which the watercraft is located; generating a variety of digital models, each modeling an impact of the environment on a corresponding capability of the watercraft; using the environmental data and the digital models, modeling an impact of the environment on the capabilities of the watercraft and creating a risk assessment for a selected action.
  • the invention is based on the objective of providing an improved military watercraft.
  • the invention concerns a military watercraft.
  • the military watercraft comprises several components, each containing one or more sensors. At least some of these components belong to a weapon system, a propulsion unit, and a navigation system.
  • the sensors are designed to acquire measured values, which indicate the operating states of the component containing the sensor and/or the state of the watercraft or its environment.
  • the military watercraft also includes a database.
  • This database persistently and securely stores a history of sensor readings along with a timestamp.
  • the military watercraft incorporates an electronic automation system.
  • This system is designed for the automatic and/or semi-automatic control of at least one of the vehicle's components in real time, based on measured values and/or user input, which is provided via a user interface in response to the output of measured values.
  • the measurement data is used directly or indirectly to control the automation system and This allows the system to influence the control of individual vehicle components.
  • the recorded measurements can be directly forwarded as input to the automation system.
  • the measurements, or at least some of them can be displayed to a user, enabling them to decide how the automation system should be operated based on these measurements.
  • a primary use of the currently valid measurement data is to influence the control of the watercraft components in real time.
  • the measurement data is also stored in a database.
  • the temporal progression of the measurement data generation can be retrieved from the database, for example, using timestamps (preferably UTC or location-independent and unique) that indicate the time of each measurement's acquisition.
  • Storing the measurement data persistently in a database allows for the automatic creation of a database over time. Analyzing this database reveals complex dependencies and interactions between multiple vehicle components and their states (engine temperature, turbine speed, rudder vibration), taking environmental parameters (temperature, humidity, pressure, depth, geographical position) into account.
  • the database content can be used as a training dataset to train a machine learning algorithm.
  • hidden, non-obvious, or technically indirect relationships and interactions can be identified, essentially in a way that is unique to each vehicle. This is particularly relevant in the military sector, where production volumes are low and many custom designs are common.
  • the measured values are stored securely in the database, which means that they are protected from unauthorized access by means of security measures, e.g. by encryption or preventing anonymous access by granting access rights.
  • the system allows for real-time vehicle monitoring as well as retrospective analysis of the history of digital measurements recorded by a vessel's sensors (regardless of whether they are integrated into the automation system). Vessel operators can thus gain valuable insights into their individual vessels based on the history stored in the database and, optionally, using their own analysis tools, even if the data originates from a complex, heterogeneous environment of vehicle components and sensors from various manufacturers. Because the measurements from different sensors and vehicle components are stored in a single database, they are accessible to a wide range of multivariate analyses, such as those used in the context of big data.
  • the timestamp which can be a UTC timestamp, allows for the unambiguous correlation of the various measurements with each other and, optionally, with the times at which control commands were sent to vehicle components or sub-components.
  • Embodiments of the invention thus enable a uniform use and analysis of all digital data that arises or can be captured by the increasingly complex platforms, systems and installations on board a military watercraft, thereby enabling seamless integration, installation, commissioning and long-term operation of the vehicle and its components.
  • Embodiments of the invention can be particularly helpful in the military sector, since users' detailed knowledge of individual vehicle components is often limited or cannot be reliably accessed under military stress. Vehicles and components are becoming increasingly complex, while crew sizes are decreasing (down to zero, which corresponds to fully autonomous vehicle control). Acquiring and storing sensor data in a database can compensate for these disadvantages.
  • the watercraft comprises several (at least two) computers networked together to form a computer cluster, which cooperate as a host in such a way that at least one instance of the database is provided. It is also possible that some or all of the database data is stored redundantly on the multiple computer systems, e.g., by creating multiple instances of the database, including some or all of the database data, on the multiple computers.
  • the watercraft includes container management software configured for the automated provisioning, scaling, and management ("orchestration") of at least one container on at least one computer in such a way that this at least one computer serves as the host system for the at least one container, wherein the at least one container isolates programs running inside it from programs running outside it.
  • the container management software orchestrates multiple containers on one or more computers.
  • the watercraft comprises several computers networked together to form a computer cluster and container management software.
  • the container management software is configured for the automated provisioning, scaling, and management ("orchestration") of several (at least two) containers on the multiple computers in such a way that each computer serves as a host system for one or more containers, with the containers (of the same host computer system as well as of different host computer systems) being isolated from each other.
  • the containers can be orchestrated to provide the database, parts of the database, and/or one or more analysis modules multiple times, enabling parallel processing. Access to identical copies of the data or analysis modules is possible.
  • the database this increases the speed of read and write access to the measurement data stored in the database and improves fault tolerance.
  • the analysis modules which are redundantly provided according to some implementations, this also increases the availability (potentially enabling parallel execution of the same type of analysis) and fault tolerance of the corresponding analysis modules.
  • Containers allow an application to be instantiated on different computers and environments (for example, different computers on a network, but also on different types of computers such as development, QA, and production). Furthermore, updates are simplified.
  • each container is access-restricted in such a way that it can only access a specific memory area of main memory assigned to it alone, as well as native applications (e.g., native databases).
  • only the analysis modules are hosted within containers, while the database is a native database on one of the is operated by a computer.
  • Corresponding embodiments of the invention can have the advantage that access to the data stored in the database can be facilitated by the analysis modules instantiated in the containers.
  • At least some of the containers are configured such that a virtual network exists between some of them, allowing the analysis modules instantiated in one container to access the contents of a database instantiated within another container networked with that container.
  • a virtual network exists between some of them, allowing the analysis modules instantiated in one container to access the contents of a database instantiated within another container networked with that container.
  • Such embodiments offer the advantage that a user can define very precisely and with fine granularity, for example via the container management software, which analysis modules within which containers can access the contents of other containers.
  • a first container might contain a first database with the measured values from sensors S1, S12, and S37, and a second container a second database with the measured values from sensors S17 and S35. Sensors S1, S12, and S37 come from manufacturer H1, while the measured values from sensors S17 and S35 come from manufacturer H2.
  • the configuration can include the analysis software A2 from manufacturer H2 running in a fourth container, which is selectively allowed to access the second database in the second container, but not the data from the sensors of manufacturer H1 in the first container.
  • the computers can be servers, i.e., computers that provide one or more programs or functions (e.g., analysis modules, databases, etc.) to external entities (e.g., other servers, analysis modules instantiated on other servers, users, etc.).
  • Server computers are often characterized by above-average computing capacities and/or above-average amounts of available main memory.
  • the military watercraft further comprises one or more analysis modules, each of which is designed to perform an analysis of at least some of the measured values stored in the database.
  • the automation system and the one or more analysis modules are operationally decoupled from each other. Additionally or alternatively, the one or more analysis modules are configured to perform their respective analysis functions without using an internet connection. In other embodiments, both the automation system and the one or more analysis modules are configured to perform their respective control or analysis functions without using an internet connection.
  • the analysis modules are designed to analyze the history of measured values stored in the database and, based on this analysis, to calculate predictions regarding the current and/or future condition of the watercraft or its components and/or to determine a technically or tactically appropriate course of action.
  • recommendations for action are first calculated, which are then implemented manually, semi-automatically, or fully automatically.
  • the analysis modules are designed to evaluate the measured values from two or more sensors of two or more different vehicle components and, optionally, one or more environmental parameters (air pressure, water temperature, depth, geographical position of the vehicle, current strength of the surrounding water, etc.).
  • environmental parameters air pressure, water temperature, depth, geographical position of the vehicle, current strength of the surrounding water, etc.
  • Executing the control and/or analysis function without using an internet connection can be advantageous, as an internet connection is often not reliably available on the high seas, and even when it is available, it may be problematic. In some cases and for some systems, the military area is switched off to increase the security of the system and reduce the probability of detection.
  • the analysis is performed on the database data, and the analysis modules are operationally separate from the automation system.
  • the operational decoupling is realized through an asynchronous operation of the automation system on the one hand and the one or more analysis modules on the other.
  • operational decoupling can involve programming the automation system and the analysis modules to operate independently of each other, meaning that at no point does the automation system require data and/or wait for data provided by the analysis module.
  • operational decoupling can be implemented in the form of asynchronous read or write access to the database by the automation system or by a service operationally connected to the automation system on the one hand, and by the one or more analysis modules on the other.
  • operational decoupling can involve the automation system receiving current measurement data directly from the sensors via a primary communication channel without writing the measurement data to the database before or during data transmission via this primary channel. This means that the automation system receives the current measurement data from the sensors directly and immediately after they are acquired, thus avoiding the delays that can occur when writing measurement data to a data storage device.
  • the measurement data is written to the database to update the history of the measurement parameters.
  • the data channel over which this writing process takes place can also be referred to as a second communication channel and could, for example, be configured as a multitude of database connections established by the sensors to the database.
  • the use of the first communication channel and one or more secondary communication channels means that even if bottlenecks or delays occur when writing the measurement data to the database, this does not lead to a delay in forwarding the measurement data to the automation system, since the data transmission to the automation system is temporally and operationally decoupled from the storage of the measurement data in the database.
  • the vessel includes a service through which the automation system reads data from the database and/or writes data generated by the automation system to the database. In this case, the read and/or write access of this service is operationally decoupled from the read/write access by the analysis modules.
  • operational decoupling can be achieved by instantiating the automation system on the one hand and the one or more analysis modules on the other hand on different computers.
  • asynchronous operation can be implemented by hosting the automation system on one or more primary computers and the database and the analysis modules on one or more secondary computers.
  • the watercraft comprises several analysis modules which are implemented in several different containers and thus isolated from one another.
  • powerful programs exist for managing containers across multiple computers. These programs allow for the redundant creation of multiple instances of an analysis module within several different containers, enabling certain analyses to be executed in parallel on different subsets of the database data, thus resulting in particularly fast performance.
  • creating multiple instances of the same analysis module ensures that even if one computer in the network fails or becomes unreachable, it is possible to immediately switch to another existing instance of the same analysis module running on a different computer, and/or that this other instance can be created in a new container on the other computer within a short time. Additionally, it is possible to quickly and flexibly increase or decrease the number and distribution of instances created by one or more analysis modules, depending on the specific requirements of the situation.
  • an analysis module which predicts the next routine service appointment for the vessel based on the distance traveled, has sufficient CPU and memory capacity available for its work, or even whether this module is instantiated at all.
  • another analysis module which uses various material and flow-related measurements at the rudder, turbine, and other vessel components, correctly calculates the next steps. It can ensure that, whether material stress limits are exceeded or the ship's stability is at risk, all necessary CPU and memory resources are available to perform its calculations correctly and quickly.
  • At most one instance of at most one of the analysis modules is executed in each of the containers.
  • the analysis modules can originate from different manufacturers of vehicle components.
  • a first analysis module could be provided by a turbine manufacturer and be configured to analyze measured values relating to the rotational speed, temperature, and vibration behavior of a turbine from the same manufacturer, equipped with sensors for these parameters.
  • This analysis can serve various purposes: for example, to determine whether critical system conditions have been reached that would void the manufacturer's warranty and/or necessitate an inspection or overhaul of the turbine.
  • the analysis can also be used to investigate how the individual measured values depend on one another, i.e., whether the turbine exhibits different vibration patterns within different speed ranges.
  • a second analysis module could be provided by an engine manufacturer and configured to analyze measured values relating to the current engine temperature, the current energy consumption of the engine, or other engine-related measurements.
  • the analysis can also serve various purposes, such as determining whether a critical engine condition has been reached or exceeded, which may result in the manufacturer's warranty becoming void and/or necessitate an inspection or overhaul of the engine.
  • the analysis could also serve to investigate how the individual measured values depend on each other, for example, whether the engine exhibits different vibration patterns and/or performance curves within different temperature ranges. Both the turbine manufacturer and the engine manufacturer, as well as ultimately the operator of the vessel itself, benefit from the fact that the analysis modules of the various manufacturers are separate.
  • running exactly one instance of an analysis module per container facilitates the orchestration of the containers, for example for the purpose of load balancing, upscaling or downscaling, since the resource consumption of a container is largely identical or strongly correlated with the resource consumption of the analysis module instantiated in that container.
  • At least some of the analysis modules are specifically assigned a portion of the database data. These data portions are stored in a protected manner such that only the analysis module assigned to that portion of the data can access it for reading and/or writing.
  • the allocation can be such that an analysis module developed by a specific company that has also manufactured a vehicle component or has a contractual relationship with the manufacturers has access to measurement data that is captured and stored by sensors of that vehicle component, but not to the measurement data of sensors of other vehicle components.
  • one or more analysis modules can be used to not only retrospectively identify individual correlations and relationships.
  • the analysis modules can not only detect critical situations but also, based on the database-stored history of measurement data from multiple sensors, predict technically and/or tactically critical situations in or on the watercraft, as well as predict instructions and control commands that can help to avoid or mitigate these critical situations.
  • the analysis modules can thus take over functions that were previously performed exclusively by the automation system.
  • the automation system is typically inflexible, as it typically integrates measurement data from a predefined number of sensors and a predefined set of vehicle components
  • the use of analysis modules in addition to the automation system is advantageous because, according to embodiments of the invention, the analysis modules are instantiated within an IT architecture that is highly available, robust, and easily scalable based on container virtualization and automatic container orchestration, and which securely protects the measurement data of the vehicle components from unauthorized access.
  • the sensors of at least one of the vehicle components contain at least one cryptographic encryption key.
  • One of the analysis modules is assigned to the at least one vehicle component and contains a decryption key corresponding to this cryptographic encryption key.
  • the two corresponding keys of the sensor and the analysis module can be a secret, symmetric cryptographic key used for both encryption and decryption of the measured values.
  • the two corresponding keys can be an asymmetric cryptographic key pair, wherein the key managed and stored by the sensor is a public cryptographic key (encryption key) and the key managed and securely stored by the analysis module is a private cryptographic key (decryption key).
  • the sensors of at least one vehicle component are designed to store at least some of the measured values they record in encrypted form in the database and/or to transmit them directly to the analysis module assigned to the at least one vehicle component.
  • At least one analysis module is configured to decrypt at least some of the measured values using the decryption key and to analyze the decrypted data.
  • all sensors mounted in or on the same vehicle component have the same public encryption key.
  • all sensors of at least one of the vehicle components of the vehicle have their own public key, which differs from the public key of the other sensors of that vehicle component.
  • the sensors of at least one of the vehicle components include a signing key.
  • the signing key preferably belongs to a Public Key Infrastructure (PKI) of a manufacturer of this vehicle component.
  • PKI Public Key Infrastructure
  • One of the analysis modules is assigned to the at least one vehicle component and includes a signature verification key corresponding to this signing key.
  • the sensors of the at least one vehicle component are configured to sign at least some of the measured values they acquire with the signing key and to store these values in signed form in the database and/or transmit them directly to the analysis module assigned to the at least one vehicle component.
  • the at least one analysis module is configured to verify the at least some measured values with the signature verification key and to analyze the signed data only if the signature verification shows that the signature is valid.
  • these analyses and forecasts are automatically translated into corresponding control commands, there is a risk that such manipulation could damage the vessel in the short or long term, or render it unusable.
  • a specific analysis module might normally be used to predict the future course for the next 5 km based on GPS position data, the current turbine rotation speed, and the current rudder angle.
  • a manipulated rudder angle sensor could provide incorrect angle data, leading to an inaccurate calculation of the vessel's course. This could result in the vessel actually being on a different course than predicted, causing it to run aground or collide with rocks.
  • This risk can be mitigated by having the sensors sign the measurement data they generate, with the signature referencing a trusted entity, such as a specific manufacturer.
  • a trusted entity such as a specific manufacturer.
  • one or more of the analysis modules are each configured to output their analysis results to a user and/or to the analysis system and/or to store them in the database.
  • the results can be displayed on a screen, printed out using a printer, and/or output via speakers. Additionally or alternatively, the results can be output to a software or hardware component, such as the automation system.
  • the results integrate data from a multitude of sensors across a wide range of vehicle components and/or environmental parameters, taking into account not only current measurements but also historical data.
  • the analysis modules are implemented as individual, isolated software modules, their number and composition can easily change over the vehicle's lifetime.
  • the composition of the vehicle components is adaptable.
  • the analysis results from the analysis modules thus represent a source of system diagnostics and control commands, which complement the functions of the automation system in a particularly flexible manner.
  • the results can be recommendations for action to a user, which must then be carried out manually.
  • they can be recommendations that can be executed automatically by the vehicle components, requiring only manual confirmation from the user.
  • they can be control commands that are sent directly from the analysis modules to the automation system without user intervention, causing the system to automatically execute the action specified in the commands, such as opening an exhaust flap, correcting the angle of a rudder, etc.
  • ML-based methods and various other forms of correlation analysis are particularly suitable for recognizing complex, cross-component, linear as well as non-linear dependencies and interactions from historical measured values of several different parameters and for calculating predictions about current and future system states based on these recognized dependencies.
  • the database data is distributed across multiple computers and/or stored redundantly.
  • At least some of the computers in the computer network are each contained in their own security container, which is fireproof and/or pressure wave resistant and/or waterproof.
  • the security container can consist of a single-walled or, preferably, a multi-walled body.
  • the body can be made of steel, for example, and equipped with a door with its own locking mechanism or lock.
  • the security container is waterproof and/or pressure wave resistant.
  • the body can include cable entry points at the rear and integrated cooling to prevent both the ingress of water and/or pressure and overheating. While "containers" are software or runtime environments for programs that are instantiated on a computer, security containers are physical containers that can hold one or more computers.
  • the computers of the computer network comprise one or more first computers and one or more second computers.
  • the first computers and the second computers are located in different spatial areas of the watercraft, wherein the different spatial areas are different rooms, different decks, different compartments separated by watertight lock gates, the starboard and port sides of the watercraft, or the bow and stern sides of the watercraft.
  • the container management software can be located on the containers.
  • Fleet analysis software can be a single, complex application program or a combination of several individual analysis programs that can perform various types of analysis on the history of measurements recorded by sensors of multiple watercraft over a period of several hours, days, weeks, months or years.
  • the computer system hosting the fleet analysis software also includes a decryption key and/or signature verification key, with these keys being provided by the manufacturer(s) of the vehicle components or the watercraft, if the manufacturers release these keys to the customer, i.e., the operator of the watercraft.
  • a "military watercraft” is understood to be a vessel trained for use by armed forces to fulfill their missions. Vessels for military purposes often have specific modifications, such as reinforced hulls or floors for mine protection, camouflage paint, and weapons and/or defense systems.
  • Watercraft are vehicles designed for movement on or in water. Specifically, they can be wind-powered or engine-powered, for example, sailing ships, hovercraft, hydrofoils, submarines, frigates, aircraft carriers, supply ships, etc. For instance, some frigates may be trained or equipped for maritime surveillance, anti-submarine warfare, combating surface vessels, and defending against air attacks on their own ship or task force. Supply ships are trained to support naval task forces, which may be composed of various ships and boats depending on the mission. The primary logistical task of a supply ship is to provide fuel, consumables, provisions, and ammunition. A supply ship can certainly do this It may also be equipped with a weapons system, e.g. to defend against enemy attacks.
  • a vehicle component refers to a part of a watercraft that, as a whole, fulfills at least one specific function.
  • a vehicle component can be a single part, i.e., an individual component of a technical complex, or a system of several components that together fulfill this function.
  • all components of a particular vehicle component are installed as a unit in a vessel.
  • a rudder system, a radar system, a weapon system, an engine unit, a control unit, etc. can each constitute a vehicle component.
  • a “sensor,” also known as a detector, (measuring) transducer, or (measuring) probe, is a technical component that can qualitatively or quantitatively detect certain physical or chemical properties (physical properties such as heat quantity, temperature, humidity, pressure, sound field quantities, brightness, acceleration; or chemical properties such as pH value, ionic strength, electrochemical potential) and/or the material composition of its environment. These properties are detected by means of physical or chemical effects and converted into a processable electrical signal.
  • This processable electrical signal can include, in particular, data that can be processed electronically and represents the quantity.
  • the processable electrical signal does not necessarily have to be generated within the detector itself, but can also be generated from the detector's output signal by electronics connected to the detector.
  • a "weapon system” refers to (often complex) technical defense equipment, particularly large-scale military equipment.
  • a component of the weapon system is the actual weapon.
  • a warship may carry weapons in the form of anti-aircraft missiles within a weapon system designed as a close-in defense system.
  • a weapon system can be a combination of individual technical elements that are interconnected. interact and, through this combination, achieve an improved weapon effect or even make it possible in the first place.
  • the Common Remotely Operated Weapon Station is a weapon system.
  • a weapon system is a gun mounted on a self-propelled gun carriage or on a ship's deck.
  • the vessel's engine power is used both to propel the vessel and to aim the gun, or the weapon system includes its own independent engine for aiming the gun.
  • An anti-aircraft missile system is another example of a weapon system.
  • the various components of the anti-aircraft missile system such as sensors (e.g., a radar system), control center, and launcher, can acquire various measurement data that are processed for monitoring, status control, and correct aiming of the radar system and/or the missiles.
  • a "drive unit” refers to the structural unit that uses energy conversion to move a machine, such as a ship's turbine. This is often a motor with a potentially necessary gearbox.
  • the drive unit can include a rotary drive or a linear drive. It can derive its energy from fossil fuels (especially oil, natural gas, and coal), nuclear energy (nuclear fission), battery power, and other energy sources.
  • a “navigation system” is understood to be a technical system that uses position determination (satellite, radio, GSM or inert or autonomous system) and geoinformation (topological, road, air or sea charts) to guide the user to a chosen location or along a route, taking desired criteria into account.
  • a “database” refers to a data structure for the structured storage of data.
  • a database can be a directory tree or a file.
  • a database is a data structure managed by a database management system (DBMS).
  • DBMS database management system
  • a DBMS is an electronic data management system designed to efficiently, consistently, and permanently store large amounts of data and to provide required subsets in various, needs-based formats for users and application programs.
  • a database system provides a database language for querying and managing the data.
  • the database can be a relational database.
  • the structure of the data is defined by a database model.
  • a "history of measured values” refers to a data set that specifies the temporal progression of several measured values.
  • a "timestamp” is understood here to be a data value that specifies a particular point in time, e.g., the date and time when a specific measurement was recorded. Timestamps are preferably given in or relative to Coordinated Universal Time (UTC). This can prevent potential misunderstandings due to globally differing time zones.
  • UTC Coordinated Universal Time
  • the term "persistently stored” here refers to the storage of data on a non-volatile storage medium.
  • protected storage here refers to data storage that technically ensures only a specific selection of users and/or applications, who can prove their authorization, can access the protected data for reading and/or writing.
  • this protection can consist of storing the data in an access-protected area and/or encrypting the data so that it can only be read by a program that possesses a suitable decryption key.
  • a “real-time capable” system such as a real-time capable automation system, is a system that is trained to perform a task in "real time".
  • Real-time means that the system is capable of continuously performing this task within a predefined maximum duration.
  • this means that the hardware and/or software system in question is subject to a "real-time constraint," for example, from event to system response.
  • Real-time programs must guarantee a response within specific timeframes, often referred to as “deadlines.” Real-time responses are often understood to be on the order of milliseconds, and sometimes microseconds or seconds.
  • a system not specified as operating in real time generally cannot guarantee a response within a timeframe, although typical or expected response times may be provided.
  • a “host” or “host computer” refers to a computer that, alone or in interaction with one or more other computers, provides a specific software program (guest software program), thus making it available to other programs and/or users.
  • the guest program can be a database, an application program, a service, or other programs and program modules.
  • a “container” is understood to be a runtime environment for software programs that includes and provides all the system components required for executing these programs and isolates the software programs running within it from programs outside the container.
  • a container can be a virtual machine created and managed by a hypervisor (a program for managing virtual machines).
  • a container is a runtime environment that can be managed using a container virtualization program.
  • Containers according to these embodiments typically require fewer resources than virtual machines because they do not start their own operating system and instead run within the context of the host operating system. Nevertheless, the containers are isolated from each other and from the host system, although not as tightly as with virtualization.
  • the free software "Docker” can be used to define containers and isolate applications from each other using container virtualization. Docker simplifies application deployment because containers, which contain all the necessary packages, can be easily transported and installed as files. Docker packages the application and all the system components required to run it into a single file, the so-called “container.” Docker containers ensure that the application runs reliably after being moved from one environment to another. This not only simplifies the deployment of complex applications on different computers but also enables a more flexible application infrastructure that is easier to modify, extend, and scale.
  • Container virtualization is a method for running multiple instances of an operating system (as so-called "guests") on a host system, isolated from one another. Unlike virtualization using a hypervisor based on multiple virtual machines, container virtualization has some limitations regarding the types of guests it can support, but it is considered particularly resource-efficient. Container virtualization is based on several principles, which are implemented differently in individual container virtualization software products. However, one core principle is always similar: multiple containers share a kernel and isolate at least some of the operating system resources used from each other.
  • the open-source program Kubernetes can be used as a container management program.
  • Kubernetes is container orchestration software that enables the simple and efficient orchestration of applications across multiple hosts.
  • Kubernetes facilitates simplified or even fully automated deployment, operation, maintenance, and scaling of container-based applications.
  • Groups of hosts running the containers are grouped into clusters of physical or virtual machines and managed as a unit.
  • Kubernetes defines a Container Runtime Interface (CRI) that container platforms must implement to be orchestrated using Kubernetes. These implementations are also known as "shims.” This makes Kubernetes platform-agnostic.
  • CRI-O or KataContainers can also be used.
  • container management software refers to software configured for the automated deployment, scaling, and management ("orchestration") of multiple (at least two) containers across multiple computers.
  • Each computer acts as a host system for one or more containers, while the containers (whether on the same host computer system or different host computer systems) remain isolated from one another. In complex environments, this can involve several hundred containers.
  • Kubernetes can be used as container management software.
  • an “analysis module” refers to software designed to process measurement data from one or more sensors using one or more different computational methods in order to generate an answer to an analytical question.
  • the software can be a script, a complex application program, a program library, or a combination of two or more of the aforementioned options.
  • the computational method can be a heuristic, a rule explicitly specified by a programmer, a mathematical and especially statistical algorithm (e.g., a correlation analysis method), or any other explicitly formulated computational procedure.
  • the computational method can also be a method that is only implicitly formulated, for example, in the form of the mathematical model of a machine learning program created during a training process. For instance, the model might be specified in the network architecture and the weights of network nodes in a neural network.
  • the analytical question can concern various issues, e.g., a question about the current or predicted future state of a vehicle component (do parameters for vibration, conductivity, elasticity, etc. indicate a critical wear state?), or a question about which measurement parameter values coincide to determine whether a critical system state has been reached or is expected to be reached in the future, or the question about the current and future availability of fuel, or Wear parts, or a question about a recommended measure to prevent or mitigate a current or future critical condition of the vehicle or a vehicle component.
  • a question about the current or predicted future state of a vehicle component do parameters for vibration, conductivity, elasticity, etc. indicate a critical wear state?
  • a question about which measurement parameter values coincide to determine whether a critical system state has been reached or is expected to be reached in the future or the question about the current and future availability of fuel, or Wear parts
  • a question about a recommended measure to prevent or mitigate a current or future critical condition of the vehicle or a vehicle component e.g., a question about the current or predicted
  • an "encryption key” refers to a cryptographic key designed for encrypting data.
  • symmetric encryption methods including all classical cryptography techniques and modern algorithms such as the Data Encryption Standard (DES) and its successor, the Advanced Encryption Standard (AES), both communicating parties use the same (secret) key for both encryption and decryption.
  • Asymmetric encryption methods such as the RSA cryptosystem, use key pairs consisting of a public key and a private key.
  • the public key is not secret; it is disclosed to at least the party that is to send encrypted data to the owner of the private key.
  • Data can be encrypted using the public key. It is crucial that a public key can be uniquely assigned to a specific entity, such as a user or an analysis module.
  • the private key is required to decrypt the ciphertext. Unlike symmetric encryption methods, where multiple parties share a secret key, in asymmetric encryption methods only one party possesses the private (secret) key. Therefore, it is fundamental that the private key cannot be derived from the public key.
  • an "automation system” is understood to be a system for the fully or semi-automatic control of a watercraft. Control is achieved by means of predefined rules based on current measured values from one or more sensors, which are converted into control commands by the automation system, and/or based on control commands entered by a user via a user interface.
  • the automation system is a real-time capable automation system.
  • the automation system is designed to not only process current measured values. and/or manually entered control commands as input and control the vehicle accordingly, but also results of the analyses from one or more of the analysis modules, whereby the automation system interprets and implements the results as control commands.
  • a “computer cluster,” or simply “cluster,” refers to a number of networked computers.
  • the cluster can be configured to increase the computing capacity and/or availability of the computers or the services they provide.
  • the computers in a computer cluster (also called “nodes") are often referred to as servers.
  • each computer in the cluster hosts one or more containers, the distribution of which across the computers is orchestrated by container management software.
  • Analysis modules or other programs which may be implemented as services, for example, can be executed within the containers, and their results can be made available to specific vehicle components. Because of this function of providing analysis results, the computers can also be called “servers.”
  • Figure 1A illustrates a block diagram of a military watercraft 100 with several sensor-equipped vehicle components.
  • the vehicle components include a propulsion system 104, which contains, for instance, a diesel-powered marine engine with a gearbox coupled to the engine.
  • the propulsion system includes several sensors for measuring various parameters of the engine and the gearbox, including a sensor 112 for the rotational speed of a shaft mechanically coupled to the gearbox.
  • the vehicle components of the watercraft include a navigation system 106 with a GPS sensor 114 for determining the current position of the vehicle, and a rudder 108 with a position or angle sensor for determining the current angle of the rudder relative to the longitudinal axis of the watercraft.
  • the vehicle incorporates an electronic monitoring unit 110 with multiple sensors, which includes several sensors 118, 120.
  • the sensors of component 110 automatically and preferably continuously or repeatedly determine vehicle and environmental parameters. These parameters include, for example, air pressure, humidity, air temperature, water temperature, water current, and/or other parameters.
  • the automation system is a fully or semi-automatic system for monitoring and controlling the internal states of the vessel, as well as for controlling the movement or other actions of the vessel or its components.
  • the automation system is a real-time system designed to use the measured values received from the sensors and user input via a user interface to control the vessel accordingly.
  • the database can be, for example, a relational database such as PostgreSQL or MySQL, or a NoSQL database.
  • the database and several analysis modules for analyzing the data are stored and instantiated in a computer system 126.
  • the computer system 126 can be a standalone, monolithic computer system. Preferably, however, it is a computer network comprising several computers connected to form a functional unit. Such a computer network is, for example, advantageous with regard to Figure 2 described in more detail.
  • the vessel also incorporates a Weapon System 102, which also includes sensors (not shown). Because the vessel, due to its weapon system, is a significant target for enemy forces and poses a potential danger to its own crew and uninvolved third parties in the event of a malfunction, the reliable operation of the automation system is of paramount importance. "Reliable operation” in this context means that the automation system, as well as the data on which it bases its decisions, must be protected from manipulation by third parties.
  • Example 1 Improved monitoring and control of a rudder system
  • the vessel in question could be an overseas vessel equipped with a rudder system, particularly a twin rudder system.
  • the rudder system has a control system designed to monitor and adjust the position of the rudders.
  • Embodiments of the invention address this problem as follows: A rudder system is used that includes a plurality of sensors for several different rudder-specific parameters, referred to here as "rudder system parameters.”
  • the rudder system parameters include two or more of the following: pressures of the rudder system's oil circuits, voltages of the rudder system's electrical control system, currents of the rudder system's electrical control system, the position of the rudders, and/or accelerations (especially vibrations) occurring at the rudder shafts.
  • the rudder system sensors are configured to regularly measure a rudder system parameter within relatively short time intervals (e.g., at least once per minute, preferably at least 10 times per second), optionally encrypt and/or sign this measurement, and store it in a database in conjunction with a timestamp.
  • the sensor's acquisition frequency can also be dynamically adjusted to the circumstances, e.g., increasing the measurement frequency when one or more relevant parameters change above a predefined threshold.
  • the timestamp can, for example, indicate the time when a measurement is saved in the database, whereby this time is very close to the time of measurement and therefore also represents this time at least approximately.
  • the position data also
  • the rudders of the rudder system are recorded by sensors as "rudder system parameters", enabling the control system to determine whether the rudders have reached the positions they are supposed to assume according to the control commands.
  • rudder system parameters In addition to these "rudder system parameters," several other sensors inside or outside the rudder system record environmental parameter values, such as the ship's speed, water temperature and/or water depth, and/or the operating states of other vessel components, such as a pump system. If, for example, the ship's speed (measured, for example, in meters of distance traveled per second) is not available, the propulsion power and/or turbine speed can alternatively be used as an indicator of speed.
  • an analysis module which, based on the recorded and stored, timestamp-linked measured values of rudder system parameters, environmental parameters, and rudder system control commands, determines the time it takes for a control command to be fully implemented by the rudders affected by the command under the prevailing conditions.
  • the analysis module uses the determined times to adjust the transmission of the control commands and/or the content of the control commands in such a way as to improve the synchronization of the rudders of the rudder system.
  • the analysis module is configured, for example, to detect correlations between measured rudder deployment times and the value ranges of rudder system parameters and environmental parameters.
  • Potential asynchronies between the port and starboard rudders can therefore be detected early and reliably, enabling timely responses and rapid, dynamic adjustments to the control commands for individual rudders, in preferred embodiments even in real time. Predicting asynchronies also allows for the forecasting of necessary maintenance work and facilitates its planning.
  • the analysis module for improved rudder control can, for example, identify potential causes of asynchronies based on acceleration and vibration data and display this information to the user.
  • the analysis considers not only the acceleration data (oscillations/vibrations) but also other rudder system parameter values and environmental parameters. This can be advantageous because oscillations and vibrations are highly dependent on water depth, rudder position, sea state, fouling, rudder system switching states, and ship speed.
  • acceleration data alone is often insufficient for precise rudder control or accurate prediction of the next required maintenance date.
  • analyzing acceleration data in combination with other rudder system parameters and environmental parameters allows for the identification of vibration states that provide information about the current deviation of the actual rudder position from the target position or the current material fatigue state of the rudder system.
  • the vehicle components of the watercraft comprise a rudder system with a control unit, one or more starboard rudders, and one or more port rudders.
  • the control unit The steering system is designed to coordinate, and in particular synchronize, the position and movement of the starboard and port rudders by sending steering commands to the starboard rudders on the one hand and to the port rudders on the other.
  • the steering system includes several sensors designed to detect steering system parameter values, where the steering system parameters comprise two or more of the following measured parameter values: current position of the rudders, rudder vibrations, fouling of the rudders (e.g., by means of an optical sensor or a force sensor that measures the force in the direction of the flow), vibrations of steering system components, and switching states of the steering system.
  • the steering system parameters comprise two or more of the following measured parameter values: current position of the rudders, rudder vibrations, fouling of the rudders (e.g., by means of an optical sensor or a force sensor that measures the force in the direction of the flow), vibrations of steering system components, and switching states of the steering system.
  • One or more of the other vehicle components and/or the steering system also include several sensors designed to detect environmental parameter values, the environmental parameters comprising two or more of the following measurement parameter values: water depth, sea state, ship speed.
  • One of the analysis modules is an analysis module for improved control of the rudder system and is designed to analyze the rudder system parameter values, the environmental parameter values, and the time periods between sending control commands from the control unit to the respective rudders and the implementation of the control commands, in order to identify correlations between the time periods, the rudder system parameter values, and the environmental parameter values, and/or to improve the coordination of the rudders of the rudder system.
  • the analysis module for improved rudder control can be trained to automatically determine that, given the current sea state and marine growth, the command to the starboard rudders must be sent 400 milliseconds earlier than the corresponding control command to the port rudders. The analysis module then sends a corresponding control command to the rudder control unit, causing the control unit to send the command to the starboard rudders only after the aforementioned delay.
  • the analysis module for improved control of the rudder system is designed to analyze the rudder system parameter values, the environmental parameter values, the time intervals between sending the control commands from the control unit to the respective rudders until the implementation of the control commands, and additionally, condition and/or vibration parameter values acquired by sensors of other vehicle components, in particular the engine and/or the transmission and/or a radar system, in order to identify correlations between the time intervals, the rudder system parameter values, the environmental parameter values, and the condition and/or vibration parameter values of the other vehicle components and/or to improve the coordination of the rudders of the rudder system.
  • a radar system could be excited by the frequency generated by a propulsion diesel engine at a certain speed, leading to a negative impact on the steering system.
  • control system can be implemented in the form of logic rules. These rules can be used not only to control the rudder system as described here, but also to control other components of the watercraft.
  • logic rules might stipulate that an internal combustion engine can only be started if at least one exhaust port is open. This rule is executed every time the engine is started, and depending on the result of the check to see if an exhaust port is open, either such a port is automatically opened or the starting process is aborted – possibly accompanied by a message to the user.
  • Example 2 Improved detection and prediction of consumption and conditions
  • one of the analysis modules is configured to calculate the current or future energy consumption and/or the current or future degree of wear of a vehicle component as a function of the temperature of the ambient water used as cooling water.
  • This data basis can, for example, automatically identify similar operating modes of the entire watercraft, e.g., operating modes defined by the temperature of the ambient water, in order to consider the evaluation of measurement data and/or other performance parameters of the entire watercraft in such a way that only comparable operating modes of the vehicle are compared with each other.
  • similar operating modes of the entire watercraft e.g., operating modes defined by the temperature of the ambient water
  • one analysis module is configured to use the temperature measured at various times to automatically identify similar operating modes of the entire watercraft, defined by a specific temperature or temperature range of the ambient water.
  • the analysis module is configured to analyze measurement data and/or other performance parameters of the entire watercraft in such a way that only comparable operating modes of the craft are compared, in order to determine, in particular, future energy consumption and the currently maximum achievable energy consumption. to calculate the possible range and/or the current or future degree of wear.
  • both the commissioning and usage phases of various vehicle components can be improved.
  • These insights can enable the automatic or manual optimization of the operating modes of individual vehicle components or the improvement of the technical characteristics of a (new) vehicle component.
  • a data acquisition system and analysis module can be developed, at least for the rudder systems of the vessels, as described in Example 1.
  • the rudder systems of the different vessels can be, but do not necessarily have to be, of the same type (i.e., from the same manufacturer). Even if the rudder systems differ slightly, at least subsystems such as the individual sensors of the rudder system or the control unit can be of the same type or comparable. Often, different manufacturers of certain vessel components use the same parts supplied by a single vendor.
  • cross-platform analyses can be performed. For example, at least some of the historical data can be imported into the central database and deleted from the vessel's own database while it is in its home port. This increases data security and reduces the storage requirements of the vessel's database.
  • fleet analysis software can analyze various environmental parameters such as air and water temperature, flow conditions, etc., to determine whether the vehicles or vehicle components were operated under comparable conditions, or to identify vehicles and components that were operated under comparable, i.e., sufficiently similar, conditions.
  • the fleet analysis software can then analyze and identify whether vehicle components of a specific type or manufacturer perform better or worse than functionally equivalent vehicle components of a different type or manufacturer with regard to one or more performance parameters. This way, a problem that has already occurred in one vehicle component can potentially be prevented in another.
  • it can determine, across all vehicles, how a specific vehicle component can be operated more efficiently, or conversely, how it should not be operated in order to avoid certain types of damage.
  • the action recommendations calculated by the fleet analysis software can be issued to a user to prompt them to make improvements to specific vehicle components, as well as components of the same or similar type.
  • individual analysis modules and/or the fleet analysis software can be configured to also calculate and issue tactical recommendations based on the data in the database(s).
  • Figure 1B Figure 150 shows a system with several military watercraft 100, 130, and 132.
  • Each of the watercraft can be configured as a watercraft of the embodiments described herein.
  • the watercraft all belong to the same or a similar type of vessel.
  • an evaluation of the sensor data histories for several watercraft can also be advantageous, for example, if the vessels of different types contain some or more vehicle components of the same type, so that a comparison of the component-related measured values is useful, at least for these vehicle components.
  • System 150 also includes a computer system 134, which can be configured as a single computer or a computer network.
  • This computer system includes an interface 136 for the secure import of the contents of the databases of the watercraft 100, 130, and 132.
  • interface 136 can be implemented in different ways. For example, it can be a wired interface, such as one based on fiber optic technology, which allows for the rapid transmission of large amounts of data. In some cases, however, it can also be a contactless interface, such as a wireless connection, or a USB interface for importing data from a portable drive via USB. In any case, several technical and/or organizational security measures are in place to ensure that the data cannot be read or manipulated during transmission.
  • the transmission can only take place using end-to-end encrypted data transmission.
  • authentication of the user initiating the data transfer may be required, e.g., via password-based and/or biometric authentication methods.
  • computer system 134 and interface 136 for secure data transmission can be part of the IT infrastructure of a home port, which can be used to import and collectively evaluate the measurement data automatically generated by the vessels during their operations.
  • the evaluation of data from multiple vessels is performed by fleet analysis software 138, which is instantiated on computer system 134.
  • the fleet analysis software analyzes the imported measurement data from the vessels' databases.
  • the imported data can be stored and analyzed, for example, in a central relational database on computer system 134.
  • the fleet analysis software automatically detects whether the measurement data from different vessels was recorded by vehicle components of the same type. This information can be helpful in ensuring that the correct measurement data is being compared.
  • a temperature sensor on an engine measures the engine temperature, while a temperature sensor on the outside of the vessel below the waterline measures the water temperature.
  • a parameter value for "temperature” originates from, because a comparison is generally only meaningful if the measurement data comes from sensors and components of the same or similar type—for example, comparing only the temperature values for the component "engine.”
  • the manufacturer is also included in the analysis. For example, different manufacturers of the same type of vehicle component (engine) may mount the sensor in slightly different positions or use different sensor types. In this case, considering the different manufacturers or other relevant circumstances can contribute to incorrect analysis results due to a misinterpretation of minor manufacturer-related measurement deviations.
  • the fleet analysis software uses imported measurement data to identify which of the vessels are optimally or worst-performing with regard to at least one specific target criterion.
  • This target criterion is a technical evaluation criterion, such as the vessel with the best energy and wear part reserves, the vessel with the least maintenance backlog, and/or the longest time until the next inspection is due.
  • the fleet analysis software identifies critical conditions of vehicle components in one or more of the vessels. For example, the fleet analysis software can identify all those vehicles in which vibration parameters indicate that within the last 6 months, temperatures and/or speed values were measured in an engine, e.g. due to material fatigue or other adverse factors, which must be considered dangerous for the vehicle component and/or the crew.
  • the fleet analysis software is designed to predict the point at which a critical condition of a vehicle component will occur in one or more of the watercraft. This could be the point at which energy, oxygen gas, or food supplies run low, when a failure of an essential component due to wear is expected, or similar events.
  • the fleet analysis software is also designed to automatically identify one or more environmental parameters and/or vehicle component parameters and their corresponding parameter value ranges that are the cause of a critical condition in one or more of the vehicle components.
  • This is a particularly advantageous aspect, especially in the context of highly complex military watercraft: sometimes vehicle components and parts fail well before their expected, normal service life, without any clear cause being identifiable. It is also sometimes observed that a specific component in a particular watercraft repeatedly fails, while the same component lasts significantly longer in other watercraft of the same type and with the same components. Given the highly complex interaction of various components and environmental factors, it is regularly assumed that the cause of the problem lies in an interaction of the component with its environment, although the specific cause responsible for the component's failure is not precisely known.
  • Figure 2 shows a block diagram of a distributed computer system 126 that can be used to store and analyze sensor measurement data.
  • the computer system shown here comprises five computers 202, 204, 206, and 208, which are functionally interconnected via a network 280, for example, an intranet, to form a computer cluster.
  • Each computer instantiates several containers 212-230.
  • Each computer has one or more processors 240, 242, 244, and 246, main memory 248, 250, 252, and optionally one or more non-volatile storage devices.
  • Each container holds and executes a maximum of one instance of an analysis module.
  • the analysis modules can each be implemented as a so-called microservice.
  • analysis module AM2 runs only as a single instance 262 within container 214
  • analysis module AM3 only as a single instance 264 in container 216
  • analysis module AM4 only as a single instance 268 in container 222.
  • some analysis modules can also run in multiple instances within a corresponding number of containers are executed.
  • the AM1 analysis module is instantiated as two instances, 260 and 266, in containers 212 and 220 respectively.
  • the number of instances of each analysis module instantiated and/or closed, and on which machine this occurs, is controlled by the container management software 256.
  • Software 256 dynamically orchestrates the instantiation, migration, and closure of containers and their contained analysis modules according to various optimization criteria, which are preferably configurable by a user. Optimization criteria can include, for example, load balancing, upscaling, and downscaling, which ensure that the computational load is evenly distributed across the machines, that some frequently used analysis modules can be executed in parallel in multiple instances, and that fast response times and/or high availability are guaranteed.
  • the measurement data acquired by the sensors of the various vehicle components of the watercraft 100 are stored in a database 122.
  • its contents are stored redundantly on the various computers 202-208.
  • Various methods for distributed, redundant data storage are known in the prior art, for example, storage using error correction methods with error correction bits.
  • some of the containers 224-230 can also be used to store parts of the database data.
  • the automation system 124 also includes one or more processors 282, working memory 284, and automation software 286.
  • the automation software is configured to dynamically receive currently acquired measurement data from at least some of the sensors and to use this data, possibly together with commands entered by a user, as input in order to derive one or more control commands from this input and to automatically control the behavior of one or more vehicle components 102, 104, 106, 108, 110 based on the control commands.
  • the computer system 290 with the automation system 124 is connected to the computer network 126 via a data communication channel 292.
  • the automation system can send a request to an access service 288 via the data connection 292 in order to read data from the distributed database 122 and use it for calculating control commands.
  • the automation system is operationally decoupled from the analysis modules; that is, it preferably runs on a different computer and, if it uses the measured values stored in the database, accesses the measured values asynchronously to the analysis modules.
  • Figure 3 shows several analysis module-specific asymmetric cryptographic key pairs that can be used for the secure transmission and storage of measurement data.
  • the propulsion system 104 can be manufactured by a first manufacturer H1.
  • Manufacturer H1 also develops an analysis module AM4, which is designed to analyze measured values acquired by one or more sensors 112 of the propulsion system in order to automatically predict the current and/or future state of the propulsion system 104.
  • manufacturer H1 Before or during the development of the analysis module AM4, manufacturer H1 generates a first asymmetric cryptographic key pair with a first secret decryption key 344 and a corresponding public encryption key 332.
  • the secret cryptographic decryption key 344 is integrated into the analysis module AM4 in such a way that it cannot be read by unauthorized third parties.
  • the speed sensor 112 of the propulsion system 104 is provided with the public encryption key 332.
  • the public keys can be generated specifically for each individual sensor of a vehicle component, along with their corresponding private keys. However, in other embodiments, it is also possible for all sensors of a vehicle component to be unique.
  • the same cryptographic key pair, or the public key of that pair, is shared, and the public key is used to encrypt the measurement data acquired by each sensor.
  • Generating key pairs individually for each sensor offers the advantage of very fine-grained access control.
  • Generating key pairs individually for each vehicle component and using the same public key for the sensors of the same vehicle component offers the advantage of simplified key management, because, as a rule (though not always), the measurement data acquired by different sensors in a vehicle have identical or similar confidentiality requirements.
  • All measured values acquired by sensor 112 for storage in database 122 are encrypted with the public key 332. This means that all other analysis modules AM1, AM2, and AM3 cannot decrypt the data acquired by speed sensor 112 and encrypted with key 332.
  • the speed sensor 112 is configured to encrypt copies of the measured values it acquires with a public key 330, which is assigned to an analysis module AM3 of another manufacturer H2, so that this analysis module AM3 can decrypt the copies with its corresponding private cryptographic key 342.
  • a public key 330 which is assigned to an analysis module AM3 of another manufacturer H2
  • this analysis module AM3 can decrypt the copies with its corresponding private cryptographic key 342.
  • contractual trust relationships may exist between manufacturer H1 and manufacturer H2 of the rudder 108, such that the sensor 112 of the drive system encrypts the measured values it acquires not only with the public key 332, but also, in copy, with the public key 330, so that not only analysis module AM4 but also analysis module AM3 can access and decrypt these measured values.
  • the vehicle component 110 which includes a temperature sensor 120 and a pressure sensor 118, can be manufactured by a third-party manufacturer H3.
  • Manufacturer H3 also develops the analysis modules AM5 and AM6, which can be instantiated in multiple copies on the computer system 126.
  • Modules AM5 and AM6 both evaluate temperature and pressure data, but for different analytical purposes and address different questions.
  • Sensor 120 generates its measurement data as two copies, encrypted with different public keys: 324 and 322.
  • Sensor 118 also generates its measurement data as two copies, encrypted with public keys 324 and 322.
  • Data encrypted with key 322 can be decrypted and processed by any analysis module containing the corresponding private key 334.
  • Data encrypted with key 324 can be decrypted and processed by any analysis module containing the corresponding private key 336.
  • Each of the multiple instances 306-312 of the AM5 analysis module contains the private key 334.
  • Each of the multiple instances 314-318 of the AM6 analysis module contains the private key 336.
  • the rudder 108 contains three sensors of different types, including the angle sensor 114. Each sensor is assigned a public key 326-330, which, together with a corresponding private key 338-342, forms an asymmetric cryptographic key pair. The measured values acquired by the sensors are encrypted in triplicate and stored in the database, each copy using a different public key.
  • Analysis module AM1 can only decrypt data encrypted with public key 326.
  • Analysis module AM2 can only decrypt data encrypted with public key 328.
  • analysis module AM3 possesses two private keys, 340 and 342, and can therefore decrypt data encrypted with either public key 328 or public key 330.
  • This precise control of access rights is particularly advantageous in the area of military vessels, because often it is a combination of specific data that is security-critical, not individual data values.
  • GPS position data is always security-critical, as it allows enemy units to launch an attack on the vessel.
  • the vessel's position below the waterline (if it is a submarine) is This alone is generally not critical, provided no further positional data is known. The same applies to data such as water temperature or current conditions.
  • combining the underwater position of the vessel with current and temperature data allows, in some cases, at least an approximate determination of the vessel's current position.
  • a single highly trusted software possesses a copy of all private keys of the analysis modules.
  • the highly trusted software could be another analysis module with extended privileges, developed by the vessel operator.
  • the fleet analysis software could possess a copy of all private keys of the analysis modules to analyze data from all sensors of all vessels in a fleet.
  • FIG. 3 This shows the assignment of private decryption keys to the individual analysis modules and the assignment of public encryption keys to the sensors (or the vehicle components containing these sensors).
  • the sensors collect measurement data and encrypt it using their assigned public keys.
  • asymmetric cryptographic key pairs are assigned to the sensors and analysis modules, but for the purpose of signature verification (not shown here).
  • private signing keys are assigned to the individual sensors or to the vehicle components containing these sensors.
  • the sensors or vehicle components use the signing keys to authenticate the acquired and optionally encrypted data. to sign measurement data.
  • the individual analysis modules have access to public signature verification keys, each of which forms an asymmetric cryptographic key pair with one of the signing keys.
  • the public signature verification keys can be part of individual analysis modules.
  • the analysis modules are configured to check the validity of the measurement data signatures with signature verification keys and to process the measurement data further only if its signature is valid.
  • the measured values can originate from the following vehicle components and subsystems: various internal measurement data (e.g., condition-related measured values of various vehicle components), SBM (damage-related measurement data, e.g., regarding damage after an accident and/or combat deployment), EBM (energy-related measurement data, e.g., condition data of a diesel generator), ONA (own noise analysis), and vibration data.
  • various internal measurement data e.g., condition-related measured values of various vehicle components
  • SBM damage-related measurement data, e.g., regarding damage after an accident and/or combat deployment
  • EBM energy-related measurement data, e.g., condition data of a diesel generator
  • ONA own noise analysis
  • vibration data is important for estimating current and future system states, as this data makes it possible in most cases to identify mechanical operational problems of rotating machinery, especially aging processes in steel structures.
  • the output interface 404 can be, for example, a screen, a speaker, or a machine-to-machine interface.
  • the interface could be a GUI that displays the results of the analysis performed by the individual analysis modules to the user (424). displays information to enable the user to take appropriate action.
  • the 410 analysis module can generate an analysis showing that the energy reserves will be depleted in three days if consumption remains constant. This result is displayed on the screen so the user can take appropriate action, such as heading to a port in time or reducing energy consumption.
  • the 112 analysis module can predict the expected range of the energy reserves by analyzing several measurements, such as currently available energy reserves, current conditions, and wind conditions, in combination with user-specified data, such as the chosen route for the next few days. If the calculation shows that the energy reserves are insufficient for the currently chosen route, but would be sufficient if an alternative route were selected, the module can suggest the alternative route. The user simply needs to confirm the alternative route to trigger the vehicle's automation system to automatically steer the vehicle onto it.
  • Some analysis modules can also output their results directly to individual vehicle components. For example, in the event of an energy emergency on the vessel, module 410 can automatically switch off all energy consumers on the vessel that are considered non-essential for the operation of the vessel, or stop supplying energy to these energy consumers.
  • At least some of the vehicle components may have a 402 interface to transmit acquired measurement data directly to one or more of the analysis modules 410-422. This can be particularly useful for measurement data that is important for fast, real-time responses from individual analysis modules, as it avoids delays caused by writing the measurement data to a database. If necessary, the measurement data can also be written to the database in the background or asynchronously.
  • the analysis modules shown here are grouped according to application areas, for example, into modules of the energy generation system (EES), the maintenance system, or the "service” system.
  • the service system includes various services, e.g., regarding the recording and/or reporting of various faults in components of the watercraft.
  • various external systems have access to the analysis modules and their results, for example via an external interface 408.
  • the interface 408 can be used, for example, to export the data from database 122 in the home port, so that fleet analysis software can evaluate the exported data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Mechanical Engineering (AREA)
  • Ocean & Marine Engineering (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Atmospheric Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Testing Or Calibration Of Command Recording Devices (AREA)
  • Time Recorders, Dirve Recorders, Access Control (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)
  • Traffic Control Systems (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

Die Erfindung betrifft ein militärisches Wasserfahrzeug (100), beinhaltend:
- mehrere Fahrzeugkomponenten (104-110), die jeweils ein oder mehrere Sensoren (112-120) beinhalten, wobei zumindest einige der Fahrzeugkomponenten zu einem Waffensystem (102), einer Antriebseinheit (104) und einem Navigationssystem (106) gehören, wobei die Sensoren zur Erfassung von Messwerten ausgebildet sind, wobei die Messwerte Betriebszustände der Fahrzeugkomponente, die den die Messwerte erfassenden Sensor beinhaltet, und/oder Zustände des Wasserfahrzeugs oder seiner Umgebung angeben;
- eine Datenbank (122), wobei in der Datenbank eine Historie von Messwerten der Sensoren in Verbindung mit einem Zeitstempel persistent und geschützt gespeichert sind; und
- ein elektronisches Automatisierungssystem (124), wobei das Automatisierungssystem ausgebildet ist zur automatischen und/oder semi-automatischen Steuerung von zumindest einer der Fahrzeugkomponenten in Echtzeit in Abhängigkeit von den Messwerten und/oder in Abhängigkeit von einer Nutzereingabe eines Nutzers, die in Antwort auf eine Ausgabe der Messwerte über eine Benutzerschnittstelle erfolgt.

Description

    Gebiet
  • Die Erfindung betrifft ein militärisches Wasserfahrzeug, insbesondere ein militärisches Wasserfahrzeug mit Sensoren zur Erfassung von Messwerten.
    • Hintergrund
  • Militärische Wasserfahrzeuge sind oftmals hochkomplexe Systeme, die für spezifische Einsatzzwecke entwickelt wurden und über eine Vielzahl von Komponenten teils unterschiedlicher Hersteller verfügen. Im Vergleich zu zivil genutzten Wasserfahrzeugen zeichnen sich militärische Wasserfahrzeuge oftmals durch eine vergleichsweise kleine Stückzahl, hohe Komplexität, hohe Anzahl an verwendeten Fahrzeugkomponenten und hohe Schutzbedürftigkeit von fahrzeugbezogenen Daten aus. Die Zusammensetzung der Fahrzeugkomponenten ist also oftmals sehr heterogen und es ist angesichts der Vielzahl und Integrationsdichte an Komponenten und Herstellern nicht immer möglich, das Zusammenspiel der einzelnen Komponenten für jedes denkbare Einsatzszenario umfassend zu testen. Hinzu kommt die Tendenz der Hersteller der Fahrzeugkomponenten, Messwerte, die durch komponenteninterne Sensoren erfasst wurden, geheim zu halten um zu verhindern, dass Dritte dieses Wissen nutzen könnten, um die Fahrzeugkomponente nachzubauen oder zu "hacken".
  • Diese Umstände stellen also erhebliche technische Hemmnisse für eine Integration der Fahrzeugkomponenten von militärischen Wasserfahrzeugen dar.
  • Die deutsche Patentanmeldung DE 102008025803 A1 beschreibt eine Schiffsbrennkraftmaschine mit einer Steuerungseinrichtung zur Steuerung und/oder Regelung des Betriebs der Schiffsbrennkraftmaschine. Die Steuerungseinrichtung bestimmt auf Grundlage der Position des Schiffs Sollbetriebsparameter für die Schiffsbrennkraftmaschine.
  • Die deutsche Patentanmeldung DE 102011 086355 A1 beschreibt ein Waffensystem zur Objektabwehr, insbesondere zum Einsatz auf Handelsschiffen, umfassend: mindestens eine Rohrwaffe, eine Schussauslösungs-Einrichtung, ein Sensorsystem zum Erfassen von Daten, insbesondere Umgebungs- und/oder Ziel-Daten, und ein Autorisierungssystem. Das Autorisierungssystem ist dabei dazu eingerichtet, die Schussauslösungs-Einrichtung abhängig von dem Empfang eines Freigabesignals freizugeben oder zu sperren.
  • Die deutsche Patentanmeldung DE 31 50 895 A 1 beschreibt ein Kampfschiff mit über elektronische Steuergerate verbundenen Anlagen. Bei dem Kampfschiff mit steuernden und gesteuerten Anlagen sind elektronische Steuergeräte vorgesehen, die aus von der zugeordneten steuernden Anlage kommenden Rohinformationen Steuersignale für die zugeordneten gesteuerten Anlagen bilden. Die elektronischen Steuergeräte weisen für jede zugeordnete gesteuerte Anlage eine Korrekturstufe zur Modifizierung dar gebildeten Steuersignale in Abhängigkeit von einem Bettungsfehler der betreffenden gesteuerten Anlage und/oder der das Steuergerat beaufschlagenden steuernden Anlage auf. Es sind weiter Speicher für die Bettungsfehlerwerte in Abhängigkeit von der Horizontalwinkellage der gesteuerten Anlage und/oder der steuernden Anlage vorgesehen.
  • Die US-Patentanmeldung US 2008 / 0 120 620 A1 beschreibt die Verwendung einer "offenen Softwarearchitektur" für die Navy-Flotte.
  • Die US-Patentanmeldung US2018/0304969A1 beschreibt ein Schiff mit einem Propeller montiert an einer drehbaren Welle und ein Verfahren zur Umwandlung der Leistung einer rotierenden Welle in Schub um das Schiff über das Wasser zu treiben. Das Verfahren umfasst die Beschaffung von Messwerten, die für die Wellenleistung beschreibend sind, eine Schätzung zweier überschüssigen Wellenleistungen verursacht durch Verschmutzung des Propellers und durch Verschmutzung des Schiffsrumpfes, und Ausgabe eines Hinweises auf die Propellerreinigung und/oder Rumpfreinigung in Abhängigkeit von den geschätzten überschüssigen Wellenleistungen.
  • Die US-Patentanmeldung US2019/0176945A1 beschreibt eine Bewegungssteuerung eines Schiffes in einer Art und Weise, die Leistung und Geräuschemission optimal ausgleicht.
  • Die US-Patentanmeldung US 2006 / 0 058 929 A1 beschreibt ein Verfahren zum Verifizieren eines Kontrollsystems eines Schiffes, in dem das Steuersystem in seinem Betriebszustand Sensorsignale von Sensoren empfängt und als Antwort Steuersignale an Aktoren sendet, um eine gewünschte Position, Geschwindigkeit, Kurs oder anderes beizubehalten.
  • Die US-Patentanmeldung US 2018 / 0 356 826 A1 beschreibt ein System und Verfahren zur Erleichterung von Entscheidungen auf einem Wasserfahrzeug. Das Verfahren umfasst: Erfassung von Umgebungsdaten der Umgebung, in der sich das Wasserfahrzeug befindet; Erzeugung einer Vielzahl von digitalen Modellen, die jeweils eine Auswirkung der Umwelt auf eine entsprechende Fähigkeit des Wasserfahrzeugs modellieren; unter Verwendung der Umweltdaten und der digitale Modelle, Modellieren einer Auswirkung der Umgebung auf die Fähigkeiten des Wasserfahrzeugs und Erstellen einer Risikobewertung für eine ausgewählte Aktion.
  • Die Veröffentlichung ANDO, Hideyuki: Smart ship application platform project (SSAP Project). In: Sea Japan 2014, Environmental Technology Seminar, 11. April 2014, 11 S. URL: https://www.mlit.go.jp/common/001039009.pdf [abgerufen am 2020-07-20] beschreibt Anwendungsdienste im Kontext eines "Smart Ships", um einen optimalen Schiffsbetrieb im Hinblick auf Sicherheit und Energieeffizienz zu erreichen.
    • Zusammenfassung
  • Der Erfindung liegt die Aufgabe zugrunde, ein verbessertes militärisches Wasserfahrzeug zur Verfügung zu stellen.
  • Die der Erfindung zugrunde liegenden Aufgaben werden jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen angegeben. Die im Folgenden aufgeführten Ausführungsformen sind frei miteinander kombinierbar, sofern sie sich nicht gegenseitig ausschließen.
  • In einem Aspekt betrifft die Erfindung ein militärisches Wasserfahrzeug.
  • Das militärische Wasserfahrzeug beinhaltet mehrere Fahrzeugkomponenten, die jeweils ein oder mehrere Sensoren beinhalten. Zumindest einige der Fahrzeugkomponenten gehören zu einem Waffensystem, einer Antriebseinheit und einem Navigationssystem. Die Sensoren sind zur Erfassung von Messwerten ausgebildet, wobei die Messwerte Betriebszustände der Fahrzeugkomponente, die den die Messwerte erfassenden Sensor beinhaltet, und/oder Zustände des Wasserfahrzeugs oder seiner Umgebung angeben.
  • Das militärische Wasserfahrzeug beinhaltet ferner eine Datenbank. In der Datenbank ist eine Historie von Messwerten der Sensoren in Verbindung mit einem Zeitstempel persistent und geschützt gespeichert.
  • Das militärische Wasserfahrzeug beinhaltet ein elektronisches Automatisierungssystem. Das Automatisierungssystem ist ausgebildet zur automatischen und/oder semi-automatischen Steuerung von zumindest einer der Fahrzeugkomponenten in Echtzeit in Abhängigkeit von den Messwerten und/oder in Abhängigkeit von einer Nutzereingabe eines Nutzers, die in Antwort auf eine Ausgabe der Messwerte über eine Benutzerschnittstelle erfolgt.
  • Dies kann vorteilhaft sein, da ein derart ausgebildetes Wasserfahrzeug die von den Sensoren erfassten Messdaten in zweifacher Weise nutzt: zum einen werden die Messdaten dazu verwendet, direkt oder indirekt das Automatisierungssystem und damit dessen Kontrolle über einzelne Fahrzeugkomponenten zu beeinflussen. Beispielsweise können die erfassten Messwerte direkt als Input an das Automatisierungssystem weitergeleitet werden. Zusätzlich oder alternativ dazu können die Messwerte oder zumindest einige von diesen einem Nutzer angezeigt werden, sodass dieser auf Basis dieser Messwerte entscheiden kann, wie das Automatisierungssystem bedient werden muss. Eine erste Verwendung der jeweils aktuell gültigen Messdaten besteht also in der Beeinflussung der Steuerung der Wasserfahrzeugkomponenten in Echtzeit. Zum anderen werden die Messdaten zusätzlich in einer Datenbank gespeichert. Dies geschieht so, dass der zeitliche Verlauf der Erzeugung der Messdaten (die "Historie" der Messwerte) der Datenbank entnehmbar ist, z. B. anhand der Zeitstempel (vorzugsweise UTC bzw. standortunabhängig und eindeutig), die jeweils den Zeitpunkt der Erfassung eines Messwerts angeben. Dass die Messdaten persistent in einer Datenbank gespeichert werden erlaubt es, automatisch mit der Zeit eine Datenbasis zu erschaffen, durch deren Analyse komplexe Abhängigkeiten und Wechselwirkungen mehrerer Fahrzeugkomponenten bzw. deren Zuständen (Temperatur Motor, Drehzahl Turbine, Vibration eines Ruders) unter Berücksichtigung von Umgebungsparametern (Temperatur, Luftfeuchte, Druck, Tiefe, geographische Position) in Erfahrung gebracht werden können. Beispielsweise kann der Inhalt der Datenbank als Trainingsdatensatz verwendet werden, um einen Machine-Learning Algorithmus auf Basis dieser Daten zu trainieren. Im Ergebnis können also verborgene , nicht offensichtliche oder technisch indirekt erkennbare Zusammenhänge und Wechselwirkungen ermittelt werden, und das im Prinzip auf eine für jedes Fahrzeug individuelle Weise, was besonders im militärischen Bereich mit geringen Stückzahlen und vielen Sonderanfertigungen von hoher Relevanz ist.
  • Die Messwerte werden geschützt in der Datenbank gespeichert, was bedeutet, dass diese mittels sicherheitstechnischer Maßnahmen vor dem Zugriff durch Unberechtigte geschützt sind, z.B. durch Verschlüsselung oder Verhinderung von anonymem Zugriff durch Vergabe von Zugriffsrechten.
  • Somit ist es möglich, im Prinzip sämtliche auf einem Wasserfahrzeug anfallenden Messwerte, die von verschiedenen Fahrzeugkomponenten und von verschiedenen Herstellern kommen können, digital zu erfassen und sowohl für die Kontrolle des Fahrzeugs in Echtzeit zu verwenden als auch zur nachträglichen Analyse einer Historie der von den Sensoren (egal ob in der Automation verfügbar oder nicht) eines Wasserfahrzeugs erfassten digitalen Messwerte. Die Betreiber des Wasserfahrzeugs haben also die Möglichkeit, auf Basis der in der Datenbank gespeicherten Historie und optional unter der Verwendung eigener Analysetools wertvolles Wissen über ein individuelles Wasserfahrzeug zu erlangen, auch wenn die Daten von einer komplexen, heterogenen Umgebung aus Fahrzeugkomponenten und Sensoren verschiedener Hersteller stammen. Da die Messwerte verschiedener Sensoren verschiedener Fahrzeugkomponenten in einer einzigen Datenbank gespeichert wurden, sind diese den verschiedensten multivariaten Analysen zugänglich, wie diese z.B. im Kontext von Big-Data verwendet werden. Der Zeitstempel, der z.B. als UTC Zeitstempel ausgebildet sein kann, erlaubt es, die verschiedenen Messwerte eindeutig zueinander und optional auch zu den Zeitpunkten, an welchen Steuerbefehle an Fahrzeugkomponenten oder Sub-Komponenten gesendet wurden, in Beziehung zu setzen.
  • Ausführungsformen der Erfindung ermöglichen also eine einheitliche Verwendung und Analyse aller anfallenden/erfassbaren digitalen Daten, die bei den immer komplexer werdenden Plattformen, Anlagen und Systemen an Bord eines militärischen Wasserfahrzeugs anfallen bzw. erfasst werden können, und ermöglichen dadurch eine reibungsfreie Integration, Installation, Inbetriebnahme und langjährigen Betrieb des Fahrzeugs und seiner Komponenten.
  • Ausführungsformen der Erfindung können insbesondere im militärischen Bereich hilfreich sein, da die Detailkenntnisse der Nutzer von einzelnen Fahrzeugkomponenten oft gering oder in militärischen Belastungssituationen nicht zuverlässig abrufbar sind. Tendenziell werden die Fahrzeuge und Komponenten immer komplexer und die Besatzungsstärke immer geringer (bis hin zu einer Besatzungsstärke von Null, was einer völlig autonomen Fahrzeugsteuerung entspricht). Die Erfassung und Speicherung der Sensordaten in der Datenbank kann diese Nachteile kompensieren.
  • Nach Ausführungsformen der Erfindung umfasst das Wasserfahrzeug mehrere (mindestens zwei) zu einem Rechnerverbund miteinander vernetzte Computer, die im Verbund als Host so zusammenarbeiten, dass zumindest eine Instanz der Datenbank bereitgestellt wird. Es ist auch möglich, dass einige oder alle Daten der Datenbank in redundanter Weise auf den mehreren Computersystemen gespeichert sind, z.B. indem mehrere Instanzen der Datenbank einschließlich einiger oder aller Daten der Datenbank auf den mehreren Computern erzeugt werden.
  • Nach Ausführungsformen umfasst das Wasserfahrzeug eine Containerverwaltungssoftware die konfiguriert ist zur automatisierten Bereitstellung, Skalierung und Verwaltung ("Orchestrierung") mindestens eines Containers auf mindestens einem der Computer auf eine Weise, dass dieser mindestens eine Computer als Hostsystem für den mindestens einen Container dient, wobei der zumindest eine Container Programme, die innerhalb dieses Containers laufen von Programmen, die außerhalb dieses Containers laufen, isoliert. Vorzugsweise orchestriert die Containerverwaltungssoftware mehrere Container auf einem oder mehreren Computern.
  • Das Wasserfahrzeug umfasst nach Ausführungsformen der Erfindung mehrere zu einem Rechnerverbund miteinander vernetzte Computer und eine Containerverwaltungssoftware. Die Containerverwaltungssoftware ist konfiguriert zur automatisierten Bereitstellung, Skalierung und Verwaltung ("Orchestrierung") mehrerer (mindestens zwei) Container auf den mehreren Computern auf eine Weise, dass die Computer jeweils als Hostsystem für ein oder mehrere Container dienen, wobei die Container (des gleichen Host-Computersystems wie auch unterschiedlicher Host-Computersysteme) voneinander isoliert sind.
  • Dies kann vorteilhaft sein, da die Integration mehrerer Computer in einen Rechnerverbund und die Verwendung einer Containerverwaltungssoftware zur Orchestrierung mehrerer auf den Computern gehosteten Containern bewirken kann, dass das System und die Bereitstellung der Datenbank und/oder einzelnen Analysemodule hoch performant und dabei auch sehr ausfallsicher ist. Beispielsweise können die Container so orchestriert werden, dass sie die Datenbank oder Teile der Datenbank und/oder ein oder mehrere Analysemodule mehrfach bereitstellen, sodass ein paralleler Zugriff auf identische Kopien der Daten bzw. Analysemodule möglich ist. Dies erhöht im Hinblick auf die Datenbank die Geschwindigkeit von Lese- und Schreibzugriffen auf die in der Datenbank gespeicherten Messwerte und erhöht die Ausfallsicherheit. Im Hinblick auf die gemäß mancher Ausführungsformen redundant bereitgestellten Analysemodule erhöht dies ebenfalls die Verfügbarkeit (ggf. parallele Durchführung des gleichen Analysetyps) und Ausfallsicherheit der entsprechenden Analysemodule. Beides ist im Kontext eines militärischen Wasserfahrzeugs von hoher Wichtigkeit, denn ein Ausfall der Datenbank und/oder von Softwareprogrammen, die in den Containern instanziiert sind, kann zu einem kritischen Datenverlust, Dateninkonsistenzen oder dem Ausfall von Prognose- und Warnfunktionen auf Basis aktuell gespeicherter oder in der Vergangenheit gespeicherten Messdaten führen. Außerdem ermöglicht die Verwendung von Containern und der Containermanagementsoftware zur Orchestrierung der Container eine einfache Skalierung des Systems, z.B. wenn im Laufe der Zeit eine deutlich größere (Mess)datenmenge gespeichert und/oder analysiert werden soll und/oder wenn die Anzahl der Softwareprogramme, die auf dem Rechnerverbund instanziiert werden soll, mit der Zeit größer wird.
  • Die Verwendung von Containern für die Bereitstellung und Isolation von Softwareapplikationen gewährleisten die Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen. Die Verwendung von Containern ermöglicht es, eine Applikation auf verschiedene Computern und Umgebungen (beispielsweise verschiedene Rechner eines Rechnernetzes, aber auch auf Rechnern unterschiedlichen Typs wie z.B. Entwicklung, QA, Produktion) zu instanziieren. Weiterhin werden Updates vereinfacht.
  • Gemäß Ausführungsformen ist jeder der Container dahingehend zugriffsbeschränkt, dass er nur auf einen bestimmten, ihm allein zugewiesenen Speicherbereich des Hauptspeichers sowie auf native Anwendungen (z.B. native Datenbanken) zugreifen kann.
  • Gemäß manchen Ausführungsformen werden nur die Analysemodule innerhalb von Containern gehostet während die Datenbank als native Datenbank auf einem der Computer betrieben wird. Entsprechende Ausführungsformen der Erfindung können den Vorteil haben, dass der Zugriff auf die in der Datenbank gespeicherten Daten durch die in den Containern instanziierten Analysemodule erleichtert werden kann.
  • Gemäß anderen Ausführungsformen sind zumindest einige der Container so konfiguriert, dass eine virtuelle Vernetzung zwischen einigen der Containern vorliegt, sodass die in einem Container instanziierten Analysemodule auf den Inhalt von einer Datenbanken, die innerhalb von einem mit dem eigenen Container vernetzten Containern instanziiert ist, zugreifen kann. Entsprechende Ausführungsformen können den Vorteil haben, dass ein Nutzer, z.B. über die Containerverwaltungssoftware, sehr genau und feingranular festlegen kann, welche Analysemodule innerhalb welcher Container auf die Inhalte anderer Container zugreifen können. Beispielsweise ist es möglich, dass ein erster Container eine erste Datenbank mit den Messwerten der Sensoren S1, S12 und S37 beinhaltet und ein zweiter Container eine zweite Datenbank mit den Messwerten der Sensoren S17 und S35. Die Sensoren S1, S12 und S37 kommen von Sensoren des Herstellers H1, die Messwerte der Sensoren S17 und S35 dagegen von Hersteller H2. Es ist nun möglich, das Computernetzwerk bzw. die Container so zu konfigurieren, dass die Analysesoftware A1 des Herstellers H1 in einem dritten Container läuft, der selektiv auf die erste Datenbank im ersten Container zugreifen darf, nicht jedoch auf die Daten der Sensoren des Herstellers H2 in dem zweiten Container. Analog kann die Konfiguration beinhalten, dass die Analysesoftware A2 des Herstellers H2 in einem vierten Container läuft, der selektiv auf die zweite Datenbank im zweiten Container zugreifen darf, nicht jedoch auf die Daten der Sensoren des Herstellers H1 in dem ersten Container.
  • Nach Ausführungsformen der Erfindung kann es sich bei den Computern um Server handeln, also um Computer, die ein oder mehrere Programme oder Funktionen (z.B. Analysemodule, Datenbanken, etc.) an externe Entitäten (z.B. andere Server, Analysemodule die auf anderen Servern instanziiert sind, Nutzern, etc.) bereitstellen. Oftmals sind Servercomputer gekennzeichnet durch überdurchschnittlich hohe Rechenkapazitäten und/oder überdurchschnittlich hohe Mengen an verfügbarem Arbeitsspeicher.
  • Erfindungsgemäß umfasst das militärische Wasserfahrzeug ferner ein oder mehrere Analysemodule, die jeweils dazu ausgebildet sind, eine Analyse von zumindest einem Teil der in der Datenbank gespeicherten Messwerte durchzuführen.
  • Nach Ausführungsformen sind das Automatisierungssystem einerseits und die ein oder mehreren Analysemodule andererseits voneinander operativ entkoppelt. Zusätzlich oder alternativ dazu sind die ein oder mehreren Analysemodule dazu ausgebildet, ihre jeweiligen Analyse-Funktion ohne Nutzung einer Internetverbindung auszuführen. Gemäß Ausführungsformen sind sowohl das Automatisierungssystem als auch die ein oder mehreren Analysemodule dazu ausgebildet, ihre jeweiligen Steuerungs- oder Analyse-Funktion ohne Nutzung einer Internetverbindung auszuführen.
  • Beispielsweise sind die Analysemodule dazu ausgebildet, die in der Datenbank gespeicherte Historie der Messwerte zu analysieren und auf Basis der Analyse Vorhersagen bezüglich des aktuellen und/oder künftigen Zustands des Wasserfahrzeugs oder seiner Komponenten und/oder eine in technischer oder taktischer Hinsicht sinnvolle Aktion zu berechnen. Insbesondere werden gemäß Ausführungsformen zunächst Handlungsempfehlungen berechnet, die dann manuell, halb- oder vollautomatisch umgesetzt werden.
  • Vorzugsweise sind zumindest einige der Analysemodule dazu ausgebildet die Messwerte von zwei oder mehr Sensoren von zwei oder mehr unterschiedlichen Fahrzeugkomponenten und optional zudem einen oder mehreren Umgebungsparameter (Luftdruck, Wassertemperatur, Tiefe, geographische Position des Fahrzeugs, Strömungsstärke des umgebenden Wassers, etc.) auszuwerten. Dies hat den Vorteil, dass auch Wechselwirkungen die zwischen den Fahrzeugkomponenten und/oder Umgebungsparametern bestehen, durch retrospektive Analyse der Historie dieser Messparameter erfassbar sind und für eine Vorhersage künftiger Zustände und Aktionen verwendet werden können.
  • Die Ausführung der Steuerungs- und/oder Analysefunktion ohne Nutzung einer Internetverbindung kann vorteilhaft sein, da eine Internetverbindung auf hoher See oftmals nicht zuverlässig verfügbar ist und sogar dann, wenn sie verfügbar ist, im militärischen Bereich in manchen Fällen und für manche Systeme abgeschaltet ist, um die Sicherheit des Systems zu erhöhen und die Detektionswahrscheinlichkeit zu verringern.
  • Die Analyse wird auf den Daten der Datenbank ausgeführt und die Analysemodule sind operativ getrennt von dem Automatisierungssystem. Das bedeutet, dass das Automatisierungssystem nicht durch Operationen für das Lesen und Verarbeiten der Messdaten durch die Analysemodule beeinträchtigt wird. Dies ist vorteilhaft, da das Automatisierungssystem ein Echtzeitsystem ist, das durch die operative Trennung davor geschützt wird, dass die Reaktionsgeschwindigkeit und/oder Responsivität des Automatisierungssystems durch die Ausführung der Analysemodule beeinträchtigt wird. Im militärischen Kontext ist es von großer Wichtigkeit, dass das Automatisierungssystem unmittelbar und in Echtzeit auf aktuelle Gegebenheiten reagieren kann, z.B. um in Gefechtssituationen automatisch die richtigen Schritte einzuleiten um das Wasserfahrzeug zu drehen, zu bremsen, zu beschleunigen, und/oder um defensive oder aggressive Maßnahmen umzusetzen.
  • Nach Ausführungsformen der Erfindung ist die operative Entkopplung realisiert durch eine asynchrone Arbeitsweise von Automatisierungssystem einerseits und den ein oder mehreren Analysemodulen andererseits.
  • Beispielsweise kann die operative Entkopplung beinhalten, dass das Automatisierungssystem und die Analysemodule so programmiert sind, dass diese unabhängig voneinander arbeiten, also an keiner Stelle das Automatisierungssystem Daten benötigt und/oder auf Daten wartet, die das Analysemodul bereitstellt.
  • Zusätzlich oder alternativ dazu kann die operative Entkopplung realisiert sein in Form eines asynchronen Schreib- oder Lesezugriff auf die Datenbank durch das Automatisierungssystem oder durch einen operativ mit dem Automatisierungssystem verbundenen Dienst einerseits und durch die ein oder mehreren Analysemodule andererseits. Beispielsweise kann die operative Entkopplung beinhalten, dass das Automatisierungssystem aktuelle Messdaten von den Sensoren über einen ersten Kommunikationskanal direkt empfängt ohne dass vor oder während der Datenübertragung über den ersten Kanal die Messdaten in die Datenbank geschrieben werden. Das bedeutet, das Automatisierungssystem erhält die aktuellen Messdaten der Sensoren direkt und unmittelbar nach deren Erfassung von den jeweiligen Sensoren und damit ohne Verzögerung die durch das Schreiben von Messdaten auf einen Datenspeicher auftreten können. Asynchron hierzu werden die Messdaten in die Datenbank geschrieben um die Historien der Messparameter fortzuschreiben. Der Datenkanal über welchen dieser Schreibprozess stattfindet kann auch als zweiter Kommunikationskanal bezeichnet werden und z.B. ausgebildet sein als eine Vielzahl von Datenbankverbindungen, die von den Sensoren im Hinblick auf die Datenbank ausgebildet werden. Die Verwendung des ersten Kommunikationskanals und der ein oder mehreren zweiten Kommunikationskanäle bedeutet, dass auch dann, falls beim Schreiben der Messdaten in die Datenbank Engpässe oder Verzögerungen auftreten sollten, dies nicht zu einer Verzögerung der Weiterleitung der Messdaten an das Automatisierungssystem führt, da die Datenübertragung der Messdaten an das Automatisierungssystem von der Speicherung der Messdaten in der Datenbank zeitlich und operativ entkoppelt ist. In einer weiteren Ausführungsform beinhaltet das Wasserfahrzeug einen Dienst, über welchen das Automatisierungssystem Daten aus der Datenbank ausliest und/oder Daten, die von dem Automatisierungssystem erzeugt wurden, in die Datenbank schreibt. Der Lese- und/oder Schreibzugriff dieses Dienstes ist in diesem Fall von den Lese-/Schreibzugriffen durch die Analysemodule operativ entkoppelt.
  • Zusätzlich oder alternativ dazu kann die operative Entkopplung realisiert sein durch eine Instanziierung des Automatisierungssystems einerseits und der ein oder mehreren Analysemodule andererseits auf unterschiedlichen Computern. Beispielsweise kann die asynchrone Arbeitsweise dadurch realisiert sein, dass das Automatisierungssystem auf einem oder mehreren ersten Computern gehostet ist und die Datenbank und die Analysemodule auf einem oder mehreren zweiten Computern. Alternativ dazu ist es auch möglich, dass dem Automatisierungssystem einerseits und der Datenbank und den Analysemodulen andererseits unterschiedliche CPU und/oder Arbeitsspeicherressourcen eines verteilten Rechnernetzes zugewiesen werden, sodass es ausgeschlossen ist, dass das Automatisierungssystem mit den Analysemodulen um Ressourcen konkurriert.
  • All diese Maßnahmen können vorteilhaft sein, da sie sicherstellen, dass das Automatisierungssystem bzw. die Echtzeitfähigkeit des Automatisierungssystems durch die Speicherung und Analyse der Historie der Messdaten nicht beeinträchtigt ist.
  • Nach Ausführungsformen der Erfindung umfasst das Wasserfahrzeug mehrere Analysemodule, die in mehreren unterschiedlichen Containern und damit isoliert voneinander ausgeführt werden.
  • Dies kann vorteilhaft sein, da dies die Ausfallsicherheit, Wartbarkeit und Performance der von den Analysemodulen ausgeführten Analyseverfahren verbessert. Beispielsweise existieren mächtige Programme zur Verwaltung von Containern auf mehreren Computern, die es ermöglichen, durch redundante Erzeugung mehrerer Instanzen eines Analysemoduls innerhalb mehrerer unterschiedlicher Container zu bewirken, dass bestimmte Analysen parallel auf unterschiedlichen Teildatensätzen der Daten der Datenbank und damit besonders schnell ausgeführt werden können. Außerdem sorgt die Erzeugung mehrerer Instanzen des gleichen Analysemoduls dafür, dass sichergestellt ist, dass auch bei Ausfall oder Unerreichbarkeit eines Rechners im Rechnerverbund sofort auf eine andere bereits existierende Instanz des gleichen Analysemoduls umgeschaltet werden kann, das auf einem anderen Rechner läuft, und/oder dass in kurzer Zeit diese andere Instanz in einem neuen Container auf dem anderen Computer erzeugt werden kann. Außerdem ist es möglich, sehr schnell und flexibel die Anzahl und Verteilung der von ein oder mehreren Analysemodulen erzeugten Instanzen zu erhöhen oder erniedrigen je nachdem was die jeweilige Situation erfordert.
  • Beispielsweise ist in einer sicherheitskritischen militärischen Operation von untergeordneter Bedeutung, ob ein Analysemodul, welches anhand der zurückgelegten Strecke den nächsten routinemäßigen Servicetermin für das Wasserfahrzeug vorhersagt, ausreichend CPU- und Arbeitsspeicher-Kapazität für seine Arbeit zur Verfügung hat oder ob dieses Modul überhaupt instanziiert ist. Es kann aber z.B. bei einem kritischen Wendemanöver von hoher Wichtigkeit sein, dass ein anderes Analysemodul, das anhand verschiedener material- und strömungsbezogener Messwerte am Ruder, der Turbine und anderen Fahrzeugkomponenten, korrekt berechnen kann, ob Materialbelastungsgrenzen überschritten oder die Stabilität des Schiffes gefährdet ist, alle erforderlichen CPU und Speicherressourcen verfügbar hat, um seine Berechnungen korrekt und schnell durchzuführen.
  • Nach Ausführungsformen der Erfindung wird in jedem der Container maximal eine Instanz von maximal einem der Analysemodule ausgeführt.
  • Dies kann vorteilhaft sein, da hierdurch sichergestellt ist, dass jede Instanz eines Analysemoduls in einem eigenen Container ausgeführt wird. Dies ermöglicht eine höchst feingranulare Orchestrierung der Analysemodule auf der Ebene einzelner Instanzen derselben mithilfe des Containermanagementprogramms.
  • Der Umstand, dass die einzelnen Analysemodule dank deren Ausführung in getrennten Containern voneinander operativ isoliert sind ist im Kontext eines militärischen Wasserfahrzeugs besonders vorteilhaft: beispielsweise können die Analysemodule von verschiedenen Herstellern von Fahrzeugkomponenten stammen. So kann zum Beispiel ein erstes Analysemodul vom Hersteller einer Turbine bereitgestellt werden und dazu ausgebildet sein, Messwerte bezüglich der Drehzahl, Temperatur und Vibrationsverhalten einer vom gleichen Hersteller stammenden Turbine mit Sensoren für Drehzahl, Temperatur und Vibrationszustand der Turbine zu analysieren. Die Analyse kann verschiedenen Zwecken dienen: zum Beispiel, um festzustellen, ob kritische Systemzustände erreicht wurden, die zum Erlöschen der Herstellergarantie führen und/oder die eine Inspektion oder eine Überholung der Turbine erforderlich machen. Die Analyse kann aber auch dazu dienen, zu untersuchen, wie die einzelnen Messwerte voneinander abhängen, also ob die Turbine zum Beispiel innerhalb verschiedener Drehzahlbereiche unterschiedliche Vibrationsmuster zeigt. Ein zweites Analysemodul kann zum Beispiel vom Hersteller eines Motors bereitgestellt werden und dazu ausgebildet sein, Messwerte bezüglich der aktuellen Motortemperatur, des aktuellen Energieverbrauchs des Motors oder sonstiger motorbezogener Messwerte zu analysieren. Die Analyse kann ebenfalls verschiedenen Zwecken dienen wie z.B. der Feststellung des Erreichens oder Überschreitens eines kritischen Motorzustands, was zum Erlöschen der Herstellergarantie führen und/oder die eine Inspektion oder eine Überholung des Motors erforderlich machen könnte. Die Analyse kann aber auch dazu dienen, zu untersuchen, wie die einzelnen Messwerte voneinander abhängen, also ob der Motor zum Beispiel innerhalb verschiedener Temperaturbereiche unterschiedliche Vibrationsmuster und/oder Leistungskurven zeigt. Sowohl der Hersteller der Turbine als auch der Hersteller des Motors wie auch letztlich der Betreiber des Wasserschiffes selbst profitieren davon, dass die Analysemodule der verschiedenen Hersteller voneinander getrennt sind, denn dadurch ist es ausgeschlossen, dass Softwareprogramme von Dritten beabsichtigterweise oder unbeabsichtigterweise mit einem bestimmten Analysemodul interagieren und dieses dazu zum Absturz bringen oder zu einer fehlerhaften Funktionsausführung führen. Gerade im militärischen Bereich muss ständig damit gerechnet werden, dass vermeintlich vertrauenswürdige Software in Wirklichkeit Schadsoftware enthält, die dazu bestimmt ist, den Betrieb von Fahrzeugen bzw. Fahrzeugkomponenten zu stören und/oder Informationen bezüglich der Funktionsweise der Fahrzeugkomponenten unberechtigterweise in Erfahrung zu bringen. Bestimmte Personen oder Organisationen könnten ein Interesse daran haben zu erfahren, wie eine bestimmte Fahrzeugkomponente arbeitet und/oder zu bewirken, dass eine Fahrzeugkomponente unzuverlässig oder fehlerhaft arbeitet und dadurch z.B. langfristig wichtige Funktionen des Wasserfahrzeugs kurzzeitig oder dauerhaft ausschaltet. Dies kann gemäß Ausführungsformen der Erfindung dadurch verhindert werden, dass die einzelnen Analysemodule isoliert voneinander jeweils innerhalb eines eigenen Containers ausgeführt werden.
  • Außerdem erleichtert die Ausführung von genau einer Instanz eines Analysemoduls pro Container die Orchestrierung der Container zum Beispiel zum Zwecke des Load-Balancing, Upscaling oder Downscaling, da der Ressourcenverbrauch eines Containers weitgehend identisch ist bzw. stark korreliert mit dem Ressourcenverbrauch des in diesem Container instanziierten Analysemoduls.
  • Nach Ausführungsformen der Erfindung ist die Containerverwaltungssoftware dazu konfiguriert, die Erzeugung von Containern, die Instanziierung und das Beenden der Analysemodulen (innerhalb dieser Container) so zu orchestrieren, dass ein oder mehrere der folgenden Wirkungen eintreten:
    • bei Ausfall oder Unerreichbarkeit einer der Computer automatisch auf einem anderen der Computer die Container und die Analysemodule gestartet werden, die durch den Ausfall oder die Unerreichbarkeit des einen Computers nicht mehr vorhanden oder erreichbar sind; hierdurch kann die Robustheit der Analysefunktionalität eines Wasserfahrzeugs gegenüber Ausfällen einzelner Rechner erhöht werden; Gerade im militärischen Bereich muss damit gerechnet werden, dass in Kampfsituationen Bestandteile des Wasserfahrzeugs wie z.B. einzelne Rechner und/oder Netzwerkverbindungen innerhalb eines Rechnerverbunds zerstört oder beschädigt werden oder zumindest kurzfristig ausfallen; durch die Fähigkeit der Containerverwaltungssoftware, in solchen Situationen eine neue Instanz des ausgefallenen Analysemoduls zu erzeugen, ist also besonders vorteilhaft; und/oder
    • bei Überschreiten einer maximalen Zahl der aktuell auf den Computern laufenden Instanzen eines der Analysemodule automatisch eine dieser Instanzen zu beenden und/oder einen der Container, der eine Instanz dieses Analysemoduls beinhaltet, zu löschen oder auf einen anderen Computer zu verschieben; dies kann vorteilhaft sein, da sicherstellt, dass nicht benötigte CPU- und SpeicherRessourcen automatisch freigegeben werden, wenn sie für analytische Tätigkeiten aktuell nicht mehr benötigt werden; umso schneller können diese freien Ressourcen im Notfall für lebenswichtige Systeme bereitgestellt werden; die "maximale Zahl" kann z.B. eine Zahl sein, die in einer Konfiguration der Containermanagementsoftware manuell oder automatisch spezifiziert wurde. Maximal bedeutet, dass eine Überschreitung dieses Werts als unerwünscht angesehen wird und eine bestimmte Folge oder Aktion induziert, die vorzugsweise dazu geeignet ist, die Zahl der Instanzen zu reduzieren; und/oder
    • bei Überschreiten einer vordefinierten maximalen Rechenlast eines der Computer automatisch zumindest einen auf diesem Computer gehosteten Container samt der darin laufende Analysemodulinstanz auf einen anderen der Computer zu migrieren; die Containerverwaltungssoftware kann also Load-Balancing Funktionen durchführen; und/oder
    • bei Unterschreiten einer vordefinierten minimalen Rechenlast eines der Computer automatisch zumindest einen auf einem anderen der Computer gehosteten Container samt der darin laufende Analysemodulinstanz auf diesen Computer zu migrieren; die Containerverwaltungssoftware kann also Load-Balancing Funktionen durchführen; in manchen Ausführungsformen kann dieser eine Computer zur Energieeinsparung deaktiviert oder in den Schlafmodus versetzt werden; und/oder
    • bei Überschreiten einer vordefinierten maximalen Rechenlast eines der Computer automatisch zumindest einen auf diesem Computer gehosteten Container samt der darin laufende Analysemodulinstanz zu identifizieren (z.B. Container mit höchstem CPU/Speicher Verbrauch oder Container der eine Instanz eines bestimmten Analysemoduls beinhaltet), eine Kopie dieses identifizierten Containers samt darin laufenden Analysemodul auf mindestens einem weiteren der Computer zu instanziieren; und Analysen unter Einbeziehung zumindest der Analysemodulinstanz in dem identifizierten Container und der weiteren instanziierten Analysemodulinstanz parallel auszuführen; die Containerverwaltungssoftware kann also Upscaling Funktionen durchführen; und/oder
    • bei Unterschreiten einer vordefinierten minimalen Rechenlast eines der Computer automatisch zumindest einen auf einem anderen Computer gehosteten Container samt der darin laufende Analysemodulinstanz zu identifizieren (z.B. Container mit höchstem CPU/Speicher Verbrauch), eine Kopie dieses identifizierten Containers samt darin laufenden Analysemodul auf diesen einen Computer zu instanziieren; und Analysen unter Einbeziehung zumindest der Analysemodulinstanz in dem identifizierten Container und der weiteren instanziierten Analysemodulinstanz parallel auszuführen; die Containerverwaltungssoftware kann also Load-Balancing Funktionen durchführen; und/oder
    • bei Unterschreiten einer vordefinierten minimalen Rechenlast eines der Computer automatisch zumindest einen der auf diesem einen Computer gehosteten Container zu löschen; die Containerverwaltungssoftware kann also Downscaling-Funktionen durchführen.
  • Dies kann vorteilhaft sein, da hierdurch der Verbrauch an CPU und ArbeitsspeicherRessourcen besser auf die Computer des Rechnerverbunds verteilt und eine bessere Reaktionszeit erreicht werden kann. Außerdem kann eine bedarfsgerechte Skalierung der Container und der darin instanziierten Analysemodule erreicht werden.
  • Nach Ausführungsformen ist zumindest einigen der Analysemodule jeweils ein Teil der Daten der Datenbank spezifisch zugewiesen. Die Teile der Daten sind auf eine Weise geschützt gespeichert, dass nur dasjenige Analysemodul auf diese lesend und/oder schreibend zugreifen kann, welches diesem Teil der Daten zugewiesen ist.
  • Beispielsweise kann die Zuweisung derart erfolgen, dass ein Analysemodul, das von einer bestimmten Firma entwickelt wurde, die auch eine Fahrzeugkomponente hergestellt hat oder mit den Herstellern in einer vertraglichen Beziehung steht, Zugriff auf Messdaten hat, die von Sensoren dieser Fahrzeugkomponente erfasst und gespeichert werden, nicht jedoch auf die Messdaten der Sensoren anderer Fahrzeugkomponenten.
  • Gemäß eines weiteren Beispiels erfolgt die Zuweisung derart, dass ein Analysemodul, das von einer bestimmten Firma entwickelt wurde, die auch mehrere Fahrzeugkomponenten hergestellt hat oder mit den Herstellern dieser Komponenten in einer vertraglichen Beziehung besteht, Zugriff auf die Messdaten hat, die von Sensoren dieser mehreren Fahrzeugkomponenten erfasst und gespeichert wurden. Auf die Messdaten der Sensoren anderer Fahrzeugkomponenten hat das Analysemodul keinen Zugriff.
  • Gemäß eines weiteren Beispiels erfolgt die Zuweisung derart, dass ein Analysemodul, das von einer bestimmten Firma entwickelt wurde, die auch ein oder mehrere Fahrzeugkomponenten hergestellt hat oder mit den Herstellern dieser ein oder mehreren Fahrzeugkomponenten in vertraglicher Beziehung steht, Zugriff auf die Messdaten hat, die von den Sensoren dieser ein oder mehreren Fahrzeugkomponenten erfasst und gespeichert wurden und zusätzlich Zugriff auf Messdaten hat, die als allgemein (für jedes Analysemodul des Wasserfahrzeugs) frei zugänglich in der Datenbank gespeichert wurden.
  • Die Analysemodule von Wasserfahrzeugen gemäß Ausführungsformen der Erfindung können den Messdaten der Datenbank gemäß einer beliebigen Kombination der hier beschriebenen Beispiele sein.
  • Die verschiedenen Formen der spezifischen Zuweisung von Messdaten und Analysemodulen kann vorteilhaft sein, da die Hersteller von Fahrzeugkomponenten dadurch sicherstellen können, dass nur Analysemodule, denen dieser Hersteller vertraut, Zugriff auf die von den Sensoren diese Fahrzeugkomponente erzeugten Messdaten haben. Die Anbringung von Sensoren verschiedenen Typs auf und/oder in Fahrzeugkomponenten eines militärischen Wasserfahrzeuges durch den Hersteller der jeweiligen Komponente hat den Vorteil, dass wichtige Zustandsparameter der Fahrzeugkomponente wie zum Beispiel Temperatur, Vibrationsverhalten, Belastungsparameter, Umgebungs-Parameter, etc. verfügbar gemacht werden. Diese Messdaten sind für den Hersteller der Fahrzeugkomponenten relevant, zum Beispiel für Test-, Entwicklungs- und Reparaturzwecke und zur Feststellung von Garantiefällen. Die Messdaten sind aber auch für den Betreiber des Wasserfahrzeugs (zum besseren Verständnis der Arbeitsweise der Fahrzeugkomponente und/oder zum besseren Verständnis von Wechselwirkungen der Fahrzeugkomponente mit anderen Komponenten oder Umgebungs-Parametern) relevant.
  • Für den Hersteller einer Fahrzeugkomponente und/oder den Betreiber des Fahrzeugs ergibt sich das Problem, dass die Preisgabe sämtlicher Messwerte gegebenenfalls Aufschluss über die Arbeitsweise und interne Komponentenzustände gibt, welche firmenintern bleiben sollten, zum Beispiel um Mitbewerbern den Nachbau zu erschweren und/oder um zu verhindern, dass Angreifer die Fahrzeugkomponente gezielt manipulieren können. Ein Hersteller von Fahrzeugkomponenten hat daher an sich kein Interesse daran, dass die Messdaten bezüglich dieser Fahrzeugkomponente offengelegt werden. Dies verhindert gegenwärtig eine Integration der Messdaten der Sensoren in verschiedene Fahrzeugkomponenten, was für den Betreiber militärischer Wasserfahrzeuge in sicherheitstechnischer Hinsicht ein Nachteil ist, denn viele technisch relevante Effekte, wie zum Beispiel ein bestimmtes Verhalten eines Ruders, einer Turbine oder einer sonstigen komplexen Komponente des Wasserfahrzeugs, ergeben sich erst aus dem komplexen Zusammenwirken mehrerer Fahrzeugkomponenten, die jeweils unterschiedliche interne Zustände aufweisen können.
  • Die beschriebene IT-Architektur wonach einzelnen Analysemodulen bestimmte Teile der Messdaten der Datenbank so zugewiesen sind, dass die Module selektiv nur auf die ihnen explizit zugewiesenen Teile zugreifen können, nicht aber generell auf alle in der Datenbank gespeicherten Messdaten, kann vorteilhaft sein, da auf Basis dieser IT Architektur der Betreiber des militärischen Wasserfahrzeugs den Lieferanten bzw. Herstellern der jeweiligen Fahrzeugkomponenten (einschließlich deren Sensoren) zusichern kann, dass die von den Sensoren erfassten Messdaten nur bestimmten Analysemodulen zugänglich sind, die von beiden Seiten als vertrauenswürdig angesehen und akzeptiert wurden. Es wird also eine IT-Architektur geschaffen, die den Herstellern militärischer Fahrzeugkomponenten ermöglicht, sensible Messdaten auf eine sichere Weise nur an bestimmte Analysemodule zur Verfügung zu stellen. Das Risiko, dass ein Mitbewerber oder Angreifer die Messdaten verwendet, um eine Fahrzeugkomponente nachzubauen oder anzugreifen kann also ausgeschlossen werden.
  • Der Betreiber des militärischen Wasserfahrzeugs profitiert davon, dass die Messdaten einer Vielzahl von Fahrzeugkomponenten gemäß Ausführungsformen der Erfindung nur an ausgewählte, vertrauenswürdige Analysemodule bereitgestellt werden: Hersteller von Fahrzeugkomponenten im militärischen Bereich tendierten bisher dazu, Messdaten von Sensoren der von diesen Herstellern erzeugten Fahrzeugkomponenten allenfalls intern zu erfassen und nur von Fahrzeugkomponenteninternen Recheneinheiten zu analysieren, ohne die Messdaten nach außen preiszugeben oder gar über einen längeren Zeitraum zu speichern. Dank der IT-Architektur von Wasserfahrzeugen gemäß Ausführungsformen der Erfindung können die Hersteller von Fahrzeugkomponenten nun auf die Komponenten-internen Recheneinheiten zur geheimen Analyse der Messdaten verzichten, da die Messdaten mehrerer Sensoren und Fahrzeugkomponenten zwar in einer Datenbank zentral gespeichert werden, dennoch aber nicht jedes Analysemodul beliebig auf diese Daten zugreifen kann.
  • Einige aktuell verfügbare Automatisierungssysteme für militärische Wasserfahrzeuge bieten zwar ebenfalls Zugriff auf Sensordaten mehrerer Sensoren, jedoch nur auf die jeweils gültigen Ist-Werte von Einzelsystemen, die nicht oder nur wenig praktikabel nutzbare historische Profile und Trends der Messwerte über einen längeren Zeitraum enthält. Aufgrund der Echtzeit-Anforderungen an solche Automatisierungssysteme hatte man bisher davon Abstand genommen, die knappen Ressourcen des Automatisierungssystems von Wasserfahrzeugen durch rechenintensive Analysen umfangreicher historischer Datenbestände zu belasten. Dank der verteilten Vorhaltung der Analysemodule in mehreren Containern in einem vom Automationssystem losgelösten Rechnerverbund ist es jedoch gemäß Ausführungsformen der Erfindung möglich, auch komplexe Analysen durchzuführen, teilweise auch in Echtzeit, und diese bereitzustellen, ohne dass die Echtzeitfähigkeit des Automatisierungssystems beeinträchtigt wird. Das Problem, dass Hersteller von Fahrzeugkomponenten mit integrierten Sensoren die von diesen erfassten Messwerte aus verschiedenen Gründen nicht preisgeben wollen bzw. können wurde durch eine IT-Architektur überwunden, die sicherstellt, dass nur ausgewählte Analysemodule mit den entsprechenden Rechten auf die Messwerte zugreifen können. Somit wurde eine IT-Architektur geschaffen, die besonders vorteilhaft im Kontext der spezifischen Gegebenheiten militärischer Wasserfahrzeuge ist.
  • Nach Ausführungsformen der Erfindung sind mehrere der Analysemodule jeweils einer der Fahrzeugkomponenten spezifisch zugewiesen und sind dazu konfiguriert, zumindest die Messwerte, die von den ein oder mehreren Sensoren dieser einen Fahrzeugkomponente, der sie zugewiesen sind, erfasst werden, direkt oder indirekt (über die Datenbank) zu empfangen, zu analysieren und das Ergebnis der Analyse auszugeben. Unter einem indirekten Empfang über die Datenbank ist gemeint, dass die von den Sensoren erfassten Messwerte zunächst in die Datenbank geschrieben werden und in einem zweiten Schritt dann das Analysemodul auf die in der Datenbank gespeicherten Messwerte zugreift. Dieser indirekte Empfang über die Datenbank hat den Vorteil, dass die Analysemodule keine Schnittstelle aufweisen müssen, um von einem bestimmten Sensor Messdaten empfangen zu können.
  • Gemäß einer Ausführungsform besitzen die ein oder mehreren Sensoren Schreibrechte auf die Datenbank und sind dazu ausgebildet, die Messwerte in geeignetem Format in der Datenbank zu speichern. Beispielsweise können die Sensoren über eine Netzwerkschnittstelle verfügen und so konfiguriert sein, dass sie die erfassten Messwerte kontinuierlich in die Datenbank schreiben.
  • Gemäß anderer Ausführungsformen sind die Sensoren dazu konfiguriert, die von ihnen erfassten Messwerte zunächst in einem lokalen flüchtigen oder nichtflüchtigen Datenspeicher des Sensors zu speichern. Eine weitere Komponente des Wasserfahrzeugs (z.B. das Automatisierungssystem, eines der Analysemodule oder eine sonstige Software) liest die lokal gespeicherten Messdaten und schreibt sie in die Datenbank, sodass die Analysemodule nun über die Datenbank auf die Messwerte zugreifen können.
  • Nach Ausführungsformen der Erfindung ist zumindest eines der mehreren Analysemodule, die einer der Fahrzeugkomponenten zugewiesen ist, dazu ausgebildet, eine Analyse durchzuführen, welche beinhaltet:
    • eine Erkennung aktueller oder künftiger kritischer Zustände der einen Fahrzeugkomponente; und/oder
    • eine Vorhersage der Zeit des Eintretens eines kritischen Zustands der einen Fahrzeugkomponente; und/oder
    • dem automatischen Identifizieren von ein oder mehreren Umgebungs-Parametern und/oder Fahrzeugkomponenten-Parametern, die ursächlich für einen kritischen Zustand der einen Fahrzeugkomponente sind; und/oder
    • eine Berechnung einer Handlungsempfehlung an einen Menschen in Bezug auf die eine Fahrzeugkomponente; und/oder
    • eine Berechnung eines Steuerbefehls an die eine Fahrzeugkomponente zur automatischen Durchführung des Steuerbefehls.
  • Dies kann vorteilhaft sein, da die ein oder mehreren Analysemodule dazu verwendet werden können, nicht nur retrospektiv einzelne Korrelationen und Zusammenhänge zu erkennen, sondern auf Basis der in der Datenbank gespeicherten Historie von Messdaten mehrerer Sensoren auch dazu verwendet werden können, technisch und/oder taktisch kritische Situationen in oder auf dem Wasserfahrzeug vorherzusagen sowie auch Handlungsanweisungen und Steuerbefehle vorherzusagen, die dazu beitragen können, die kritische Situation zu vermeiden oder abzumildern. Die Analysemodule können somit Funktionen übernehmen, die bisher ausschließlich von dem Automatisierungssystem wahrgenommen wurden. Während das Automatisierungssystem typischerweise wenig flexibel ist, da es typischerweise Messwerte einer vordefinierten Anzahl von Sensoren einer vordefinierten Menge an Fahrzeugkomponenten integriert, ist die Verwendung von Analysemodulen in Ergänzung zum Automatisierungssystem vorteilhaft, da die Analysemodule gemäß Ausführungsformen der Erfindung innerhalb einer IT-Architektur instanziiert sind, die auf Basis von Containervirtualisierung und automatischer Containerorchestrierung hochverfügbar, robust und leicht skalierbar ist und die die Messdaten der Fahrzeugkomponenten auf sichere Weise vor Zugriff durch unberechtigte Dritte schützt.
  • Nach Ausführungsformen der Erfindung beinhalten die Sensoren von zumindest einer der Fahrzeugkomponenten zumindest einen kryptographischen Verschlüsselungsschlüssel. Eines der Analysemodule ist der zumindest einen Fahrzeugkomponente zugeordnet und beinhaltet einen zu diesem kryptographischen Verschlüsselungsschlüssel korrespondierenden Entschlüsselungsschlüssel. Bei den beiden "korrespondierenden" Schlüsseln des Sensors und des Analysemoduls kann es sich um einen geheimen, "symmetrischen" kryptographischen Schlüssel handeln, der sowohl zur Ver- als auch Entschlüsselung der Messwerte verwendet wird. Alternativ dazu kann es sich bei den beiden korrespondierenden Schlüsseln um ein asymmetrisches kryptographisches Schlüsselpaar handeln, wobei der von dem Sensor verwaltete und gespeicherte Schlüssel ein öffentlicher kryptographischer Schlüssel (Verschlüsselungsschlüssel) ist und wobei der von dem Analysemodul verwaltete und sicher gespeicherte Schlüssel ein privater kryptographische Schlüssel (Entschlüsselungsschlüssel) ist. Die Sensoren der zumindest einen Fahrzeugkomponente sind dazu ausgebildet, zumindest einige der von ihnen erfassten Messwerte in verschlüsselter Form in der Datenbank zu speichern und/oder direkt an das der zumindest einen Fahrzeugkomponente zugewiesene Analysemodul zu übermitteln.
  • Das zumindest eine Analysemodul ist dazu konfiguriert, die zumindest einigen Messwerte mit dem Entschlüsselungsschlüssel zu entschlüsseln und die entschlüsselten Daten zu analysieren.
  • Gemäß Ausführungsformen der Erfindung haben alle Sensoren, die in oder an derselben Fahrzeugkomponente angebracht sind, den gleichen öffentlichen Verschlüsselungsschlüssel. Gemäß anderen Ausführungsformen der Erfindung haben alle Sensoren von zumindest einer der Fahrzeugkomponenten des Fahrzeugs einen eigenen öffentlichen Schlüssel, der sich vom öffentlichen Schlüssel der anderen Sensoren dieser Fahrzeugkomponente unterscheidet.
  • Dies kann vorteilhaft sein, da die Verwendung von Verschlüsselungsverfahren ein besonders hohes Maß an Sicherheit dafür bietet, dass die Messdaten von Sensoren einer bestimmten Fahrzeugkomponente ausschließlich von berechtigten Analysemodulen gelesen und interpretiert werden können.
  • Nach Ausführungsformen der Erfindung beinhalten die Sensoren von zumindest einer der Fahrzeugkomponenten einen Signierschlüssel. Der Signierschlüssel gehört vorzugsweise zu einer PKI eines Herstellers dieser Fahrzeugkomponente. Eines der Analysemodule ist der zumindest einen Fahrzeugkomponente zugeordnet und beinhaltet einen zu diesem Signierschlüssel korrespondierenden Signaturprüfschlüssel. Die Sensoren der zumindest einen Fahrzeugkomponente sind dazu ausgebildet, zumindest einige der von ihnen erfassten Messwerte mit dem Signierschlüssel zu signieren und diese in signierter Form in der Datenbank zu speichern und/oder direkt an das der zumindest einen Fahrzeugkomponente zugewiesene Analysemodul zu übermitteln. Das zumindest eine Analysemodul ist dazu konfiguriert, die zumindest einigen Messwerte mit dem Signaturprüfschlüssel zu prüfen und die signierten Daten nur dann zu analysieren, wenn die Signaturprüfung ergibt, dass die Signatur valide ist.
  • Dies kann vorteilhaft sein, da hierdurch der Betreiber des Wasserfahrzeugs davor geschützt wird, dass ein Angriff auf die Stabilität und Integrität des militärischen Wasserfahrzeugs dadurch erfolgt, dass eine manipulierte Fahrzeugkomponente und/oder manipulierte Sensoren falsche Analysen und Prognosen erzeugt. Insbesondere dann, wenn diese Analysen und Prognosen automatisch in entsprechende Steuerbefehle umgesetzt werden, besteht die Gefahr, dass durch eine derartige Manipulation das Wasserfahrzeug kurzfristig oder langfristig beschädigt oder nicht mehr einsatzfähig gemacht wird. Beispielsweise kann ein bestimmtes Analysemodul normalerweise dazu verwendet werden, auf Basis von GPS Positionsdaten, der aktuellen Rotationszahl der Turbine und einem aktuellen Winkel des Steuerruders den künftigen Kurs für die nächsten 5 km vorherzusagen. Ein manipulierter Winkelsensor des Steuerruders kann falsche Winkeldaten liefern, die dazu führen, dass der Kurs des Wasserfahrzeugs falsch berechnet wird. Dies kann dazu führen, dass das Schiff sich faktisch auf einem anderen Kurs befindet als dem vorhergesagten und auf Grund aufläuft oder mit Felsen kollidiert. Diese Gefahr kann dadurch behoben werden, dass die Sensoren die von Ihnen erzeugten Messdaten signieren, wobei die Signatur auf eine vertrauenswürdige Instanz, zum Beispiel einen bestimmten Hersteller, verweist. Dadurch, dass das Analysemodul die Signatur der Messdaten prüft, bevor es diese verwendet, kann ausgeschlossen werden, dass manipulierte Sensoren und/oder manipulierte Fahrzeugkomponenten Fahrzeug und Besatzung bedrohen.
  • Nach Ausführungsformen der Erfindung sind eines oder mehrere der Analysemodule jeweils dazu konfiguriert, ihr Ergebnis der Analyse an einen Nutzer und/oder an das Analysesystem auszugeben und/oder in der Datenbank zu speichern.
  • Beispielsweise können die Ergebnisse auf einem Bildschirm angezeigt, mittels eines Druckers ausgedruckt und/oder per Lautsprecher ausgegeben werden. Zusätzlich oder alternativ dazu können die Ergebnisse an eine Software oder Hardwarekomponente ausgegeben werden, zum Beispiel an das Automatisierungssystem.
  • Dies kann vorteilhaft sein, da die Ergebnisse die Daten einer Vielzahl von Sensoren einer Vielzahl von Fahrzeugkomponenten und/oder Umgebungsparameter integrieren und hierbei nicht nur aktuelle Messwerte, sondern auch die Historie der Messwerte berücksichtigen können. Da die Analysemodule als einzelne, isolierte Software Module implementiert sind, sind Anzahl und Zusammensetzung der Analysemodule leicht an sich im Laufe der Lebenszeit des Fahrzeugs möglicherweise ändernde Zusammensetzung der Fahrzeugkomponenten anpassbar. Die Analyseergebnisse der Analysemodule stellen somit eine Quelle für Systemdiagnosen und Steuerbefehle dar, welche die Funktionen des Automatisierungssystems auf besonders flexible Weise ergänzen. Je nach Art des Analyseergebnisses und Implementierung können die Analyseergebnisse Handlungsempfehlungen an einen Nutzer sein, wobei die Handlungen von dem Nutzer bzw. manuell ausgeführt werden müssen. Es kann sich auch um Handlungsempfehlungen handeln, die automatisch von den Fahrzeugkomponenten ausgeführt werden können und deren Ausführung vom Nutzer lediglich nochmals manuell bestätigt werden muss. Es kann sich auch um Steuerbefehle handeln, die direkt und ohne den Nutzer einzubeziehen direkt von den Analysemodulen an das Automatisierungssystem gegeben werden und dieses dazu veranlassen, automatisch die in den Befehlen spezifizierte Aktion auszuführen, z.B. eine Abluftklappe zu öffnen, den Winkeln eines Ruders zu korrigieren, etc.
  • Nach Ausführungsformen der Erfindung ist zumindest eines der Analysemodule dazu ausgebildet, eine Analyse (z.B. Korrelationsanalyse, Machine-Learning (ML) basierten Vorhersage, regelbasierte Vorhersage, etc.) auf den Messwerten mehrerer (mindestens zwei) unterschiedlicher Sensoren von mehreren unterschiedlichen Fahrzeugkomponenten durchzuführen. Die Analyse beinhaltet:
    • eine Erkennung aktueller oder künftiger kritischer Zustände von einer Fahrzeugkomponente; und/oder
    • eine Vorhersage der Zeit des Eintretens eines kritischen Zustands einer Fahrzeugkomponente; und/oder
    • dem automatischen Identifizieren von ein oder mehreren Umgebungs-Parametern und/oder Fahrzeugkomponenten-Parametern, die ursächlich für einen kritischen Zustand einer der Fahrzeugkomponenten sind; und/oder
    • eine Berechnung einer Handlungsempfehlung an einen Menschen; und/oder
    • eine Berechnung eines Steuerbefehls an eine der Fahrzeugkomponenten zur automatischen Durchführung des Steuerbefehls.
  • Dies kann vorteilhaft sein, da ML-basierte Verfahren und verschiedene andere Formen der Korrelationsanalyse besonders dafür geeignet sind, aus historischen Messwerten mehrerer unterschiedlicher Parameter komplexe, komponentenübergreifende, lineare wie nichtlineare Abhängigkeiten und Wechselwirkungen zu erkennen und auf Basis dieser erkannten Abhängigkeiten Vorhersagen über aktuelle und künftige Systemzustände zu berechnen.
  • Nach Ausführungsformen der Erfindung sind die Daten der Datenbank in den mehreren Computern verteilt und/oder redundant gespeichert.
  • Dies kann vorteilhaft sein, da die Ausfallsicherheit erhöht wird, falls einer der Rechner ausfällt oder nicht erreichbar ist. Außerdem erlaubt eine redundante Speicherung parallelen Zugriff auf Kopien der gleichen Daten und damit eine Beschleunigung der Abfrage.
  • Nach Ausführungsformen der Erfindung sind die Daten der Datenbank verteilt in verschiedenen Containern verschiedener Rechner gespeichert (die Container sind also auf verschiedenen Rechnern instanziiert, wobei auf einigen Rechnern auch mehrere Container instanziiert sein können). Die Containerverwaltungssoftware ist dazu konfiguriert, die Erzeugung von Containern und die Speicherung, Replikation und Löschung der Daten in den Containern so zu orchestrieren, dass:
    • im Normalbetrieb die Daten der Datenbank in redundanter Weise so in den mehreren Computern verteilt gespeichert werden, sodass diese bei Ausfall von einem oder mehreren der Computer aus den in den übrigen Computern gespeicherten Daten rekonstruierbar sind; und/oder
    • bei Ausfall eines der Computer automatisch ein anderer der Computer, auf welchem eine Kopie derjenigen Teile der Daten, die in dem ausgefallenen Computer gespeichert waren, identifiziert wird, und die auf diesem anderen Computer enthaltenen Daten den Analysemodulen und der Automatisierungssystem bereitgestellt werden (z.B. durch Starten dieses anderen Computers, Freigabe eines Zugriffs auf die Teildaten, etc.); und/oder
    • bei Ausfall eines der Computer automatisch Neuverteilung zumindest eines Teils der in mehreren Containern redundant und verteilt gespeicherten Daten derart, dass der bisherige Grad der Redundanz der Daten der Datenbank wiederhergestellt wird; und/oder
    • bei Überschreiten eines vordefinierten maximalen Speicherbedarfs in einem der Computer automatisch zumindest Teile der auf diesem Computer gespeicherten Daten der Datenbank auf einen anderen der Computer zu migrieren oder zu kopieren; hierfür können z.B. Load-Balancing-Funktionen wie sie z.B. in der Software Kubernetes bereits enthalten sind verwendet werden.
  • Dies kann aus analogen Gründen wie die redundante Instanziierung der Analysemodule auf mehreren Computern vorteilhaft sein. Insbesondere wird die Verfügbarkeit und Ausfallsicherheit erhöht und Zugriffszeiten durch parallelen Zugriff verkürzt.
  • Nach Ausführungsformen der Erfindung sind zumindest einige der Rechner des Rechnernetzwerks jeweils in einem eigenen Sicherheitsbehälter enthalten, der feuerfest und/oder druckwellen-robust und/oder wasserdicht ist.
  • Beispielsweise kann der Sicherheitsbehälter aus einem einwandigen oder vorzugsweise mehrwandigen Korpus bestehen. Der Korpus kann z.B. aus Stahl bestehen und eine Tür mit für den Korpus jeweils eigenen Verriegelungsmechanismus bzw. Schloss versehen sein. Vorzugsweise ist der Sicherheitsbehälter wasserdicht und/oder druckwellenstabil. Beispielsweise kann der Korpus Kabeldurchführungsöffnungen an der Rückseite und eine integrierte Kühlung beinhalten um einerseits ein Eindringen von Wasser und/oder Druck und andererseits ein Überhitzen zu vermeiden. Während es sich also bei den "Containern" um Software bzw. Laufzeitumgebungen für Programme handelt, die auf einem Rechner instanziiert werden, handelt es sich bei den Sicherheitsbehältern um physische Behälter, die ein oder mehrere Rechner beinhalten können.
  • Dies kann vorteilhaft sein, da die Rechner und damit auch die Analyseprogramme und Container im Falle eines Lecks oder einer Detonation (Druckwelle, Feuer) vor Beschädigung geschützt sind.
  • Nach Ausführungsformen der Erfindung umfassen die Rechner des Rechnernetzwerks ein oder mehrere erste Rechner und ein oder mehrere zweite Rechne. Die ersten Rechner und die zweiten Rechner sind in unterschiedlichen räumlichen Bereichen des Wasser-fahrzeugs untergebracht, wobei die unterschiedlichen räumlichen Bereiche unterschiedliche Zimmer, unterschiedliche Decks, unterschiedliche durch wasserdichte Schleusentore getrennte Kammern, Steuerbordseite und Backbordseite des Wasserfahrzeugs oder Bugseite und Heckseite des Wasserfahrzeuges sind.
  • Dies kann vorteilhaft sein, da die Ausfallsicherheit des Wasserfahrzeuges und der Analysemodule erhöht wird: sollten wegen einer Detonation oder einer Havarie bestimmte Bereiche des Schiffs beschädigt werden, sind davon nicht alle Analysemodule betroffen. Vielmehr kann die Containerverwaltungssoftware auf den Containern.
  • In einem weiteren Aspekt betrifft die Erfindung ein System umfassend mindestens zwei militärische Wasserfahrzeuge gemäß einer der hier beschriebenen Ausführungsformen oder Beispiele und ein Computersystem. Das Computersystem beinhaltet eine Schnittstelle zum sicheren Import des Inhalts der Datenbanken der mindestens zwei Wasserfahrzeuge. Das Computersystem beinhaltet außerdem eine Flottenanalysesoftware. Die Flottenanalysesoftware ist dazu ausgebildet, die Messwerte der Datenbanken der mindestens zwei Wasserfahrzeugen zu analysieren. Die Flottenanalysesoftware ist dazu konfiguriert, automatisch zu erkennen, ob die Messwerte unterschiedlicher Wasserfahrzuge von Fahrzeugkomponenten gleichen Typs erfasst wurden. Die Analyse umfasst:
    • eine Erkennung desjenigen der Wasserfahrzeuge, dessen Gesamtheit an Fahrzeugkomponenten im besten oder schlechtesten Zustand ist im Hinblick auf zumindest ein technisches Bewertungskriterium (z.B. Füllstand Tank, Verfügbarkeit von Energieressourcen, Zeit bis zur nächsten Wartung, Indikator der Ausfallsicherheit, Indikator der Geeignetheit des Wasserfahrzeug für bestimmtes Einsatzszenario; ); und/oder
    • eine Erkennung kritischer Zustände von einer Fahrzeugkomponente in einem oder mehreren der Wasserfahrzeuge; beispielsweise kann durch Analyse historischer Messdaten in den Datenbanken der mehreren Wasserfahrzeuge erkannt werden, dass bei einigen wenigen Wasserfahrzeugen eine Kombination aus Anstellwinkel des Ruders und der Drehzahl der Turbine, die bei der Mehrzahl der Wasserfahrzeuge unproblematisch war, einen instabilen Zustand des Wasserfahrzeugs bewirkt hat, die manuelles Eingreifen erforderlich gemacht hat, sodass diese wenigen Fahrzeuge zur Inspektion gebracht werden sollten; bestimmte Vibrationsmuster können erkennen lassen, dass eine Fahrzeugkomponente eines bestimmten Wasserfahrzeugs an Materialermüdung leidet oder von Vibrationen und Bewegungen benachbarter Komponenten negativ beeinflusst wird, sodass auch für dieses eine Inspektion empfehlenswert scheint; und/oder
    • eine Vorhersage der Zeit des Eintretens eines kritischen Zustands einer Fahrzeugkomponente in einem oder mehreren der Wasserfahrzeuge; beispielsweise kann der Zeitpunkt, wann angesichts der anhand der Vibrationswerte ableitbaren Materialermüdung und/oder angesichts der üblichen Wartungsintervalle jedes der Wasserfahrzeuge den nächsten Inspektionstermin hat, sodass dasjenige Fahrzeug, dessen vorhergesagter Inspektionstermin am weitesten in der Zukunft liegt als das geeignetste für einen aktuellen, längeren Einsatz angesehen werden kann; und/oder
    • dem automatischen Identifizieren von ein oder mehreren Umgebungs-Parametern und/oder Fahrzeugkomponenten-Parametern, die ursächlich für einen kritischen Zustand einer der Fahrzeugkomponenten in einem oder mehreren der Wasserfahrzeuge sind; beispielsweise kann die Flottenanalysesoftware erkennen, dass nur diejenigen Schiffe, die in Gewässern mit einer Wassertemperatur von unter 6 °C unterwegs waren, Probleme mit dem Auslösen einer Bewegung bei einem bestimmten Bauteil hatten, sodass die Vermutung naheliegt, dass die Materialkontraktion bei niedrigen Temperaturen Auslöser für die Probleme war und das Bauteil nicht geeignet für den Einsatz bei niedrigen Temperaturen ist. Die Analyse mehrerer Wasserfahrzeuge kann es hier ggf. ermöglichen,
    Ursachen aufzudecken, die ohne die Daten mehrerer Fahrzeuge auszuwerten, nicht oder wahrscheinlich nicht erkannt worden wären.
  • Bei der Flottenanalysesoftware kann es sich um ein einzelnes, komplexes Applikationsprogramm handeln oder um eine Kombination mehrerer einzelner Analyseprogramme, die verschiedene Arten von Analysen auf den Historien von Messwerten, die von Sensoren mehrerer Wasserfahrzeuge über einen Zeitraum von mehreren Stunden, Tagen, Wochen, Monaten oder Jahren erfasst wurden, durchführen können.
  • Gemäß mancher Ausführungssysteme beinhaltet das Computersystem, das die Flottenanalysesoftware hostet, auch einen Entschlüsselungsschlüssel und/oder Signaturprüfschlüssel, wobei diese Schlüssel von dem/den Hersteller(n) der Fahrzeugkomponenten oder der Wasserfahrzeuge bereitgestellt werden, falls die Hersteller diese Schlüssel für den Kunden, also den Betreiber des Wasserfahrzeugs, freigeben.
  • Unter einem "militärischen Wasserfahrzeug" wird hier ein Wasserfahrzeug verstanden, das dazu ausgebildet ist, von Streitkräften zur Erfüllung ihrer Aufgaben verwendet zu werden. Oftmals haben Fahrzeuge für militärische Zwecke spezifische Anpassungen, z.B. verstärkte Wände oder Böden zum Schutz vor Minen, einen Tarnanstrich, Waffen- und/oder Verteidigungssysteme. Wasserfahrzeuge sind Fahrzeuge, die zur Fortbewegung auf dem oder im Wasser bestimmt sind. Insbesondere kann es sich um ein windbetriebenes oder ein maschinenbetriebenes Wasserfahrzeug handeln, z.B. Segelschiffe, Luftkissenboote, Tragflächenboote, UnterseeBoote, Fregatten, Flugzeugträger, Versorgungsschiffe, etc. Beispielsweise können manche Fregatten zur Seeraumüberwachung, Ubootjagd, Bekämpfung von Überwassereinheiten und Abwehr von Luftangriffen. auf das eigene Schiff bzw. den Verband ausgebildet bzw. ausgerüstet sein. Versorgungsschiffe sind dazu ausgebildet, Einsatzgruppen der Marine, die sich aufgabenorientiert aus unterschiedlichen Schiffen und Booten zusammensetzen können, zu unterstützen. Die logistische Hauptaufgabe eines Versorgungsschiffes besteht in der Versorgung mit Betriebsstoffen, Verbrauchsgütern, Proviant und Munition. Dabei kann ein Versorgungsschiff durchaus auch mit einem Waffensystem versehen sein, z.B. um feindliche Übergriffe abzuwehren.
  • Unter einer "Fahrzeugkomponente" wird hier ein Teil des Wasserfahrzeugs verstanden, das in seiner Gesamtheit zumindest eine bestimmte Funktion erfüllt. Eine Fahrzeugkomponente kann ein Bauteil, also ein Einzelteil eines technischen Komplexes sein, oder ein System aus mehreren Bauteilen, die in Ihrer Gesamtheit diese Funktion erfüllen. Typischerweise werden alle Bestandteile einer bestimmten Fahrzeugkomponente als Einheit in ein Fahrzeug verbaut. Beispielsweise können eine Ruderanlage, eine Radaranlage, ein Waffensystem, eine Motoreinheit, eine Steuereinheit etc. jeweils eine Fahrzeugkomponente darstellen.
  • Unter einem "Sensor", auch als Detektor, (Messgrößen- oder Mess-)Aufnehmer oder (Mess-)Fühler bezeichnet, ist ein technisches Bauteil, das bestimmte physikalische oder chemische Eigenschaften (physikalisch z. B. Wärmemenge, Temperatur, Feuchtigkeit, Druck, Schallfeldgrößen, Helligkeit, Beschleunigung oder chemisch z. B. pH-Wert, Ionenstärke, elektrochemisches Potential) und/oder die stoffliche Beschaffenheit seiner Umgebung qualitativ oder als Messgröße quantitativ erfassen kann. Diese Größen werden mittels physikalischer oder chemischer Effekte erfasst und in ein weiterverarbeitbares elektrisches Signal umgeformt. Dabei kann das weiterverarbeitbare elektrische Signal insbesondere datentechnisch verarbeitbare Daten umfassen, die eine Repräsentation der Größe darstellt. Das weiterverarbeitbare elektrisches Signal muss dabei nicht unbedingt im Detektor selbst erzeugt werden, sondern kann auch durch an den Detektor angeschlossene Elektronik aus dem Ausgabesignal des Detektors erzeugt werden.
  • Unter einem "Waffensystem" wird hier ein (oftmals komplexes) technisches Wehrmaterial, insbesondere militärisches Großgerät, verstanden. Ein Bestandteil des Waffensystems ist die eigentliche Waffe. Beispielsweise kann ein Kriegsschiff Waffen in Form von Luftabwehrflugkörpern in innerhalb eines als Nahbereichsverteidigungssystem ausgebildeten Waffensystems beinhalten. Insbesondere kann ein Waffensystem ein Verbund einzelner technischer Elemente sein, welche untereinander wechselwirken und durch diesen Verbund eine verbesserte Waffenwirkung erzielen oder überhaupt erst ermöglichen.
  • Beispielsweise ist die "Common Remotely Operated Weapon Station" (CROWS) ein Waffensystem. Ein weiteres Beispiel für ein Waffensystem ist ein Geschütz auf einer Selbstfahrlafette oder einem Schiffsdeck. Je nach Ausführungsform wird die Motorleistung des Wasserfahrzeugs sowohl für den Antrieb des Wasserfahrzeugs als auch zum Richten des Geschützes verwendet oder das Waffensystem beinhaltet einen eigenen, unabhängigen Motor zum Ausrichten des Geschützes. Ein Flugabwehrraketensystem ist ein weiteres Beispiel für ein Waffensystem. Die verschiedenen Elemente wie Sensoren (z. B. eine Radaranlage), Steuerstelle und Startanlage des Flugabwehrraketensystems können verschiedene Messdaten erfassen, die zur Überwachung, Statuskontrolle und korrekten Ausrichtung der Radaranlage und/oder der Raketen verarbeitet werden.
  • Unter einer "Antriebseinheit" wird hier die konstruktive Einheit bezeichnet, die mittels Energieumformung eine Maschine, z.B. eine Schiffsturbine, bewegt. Häufig ist dies ein Motor mit einem eventuell notwendigen Getriebe. Die Antriebseinheit kann einen Drehantriebe oder einen Linearantrieb beinhalten. Die Antriebseinheit kann ihre Energie aus fossilen Quellen (insb. Öl, Erdgas, Kohle), Atomenergie (Kernspaltung), Batteriekraft und anderen Energieträgern beziehen.
  • Unter einem "Navigationssystem" wird hier ein technisches System verstanden, das mit Hilfe von Positionsbestimmung (Satellit, Funk, GSM bzw. inertes oder autonomes System) und Geoinformationen (Topologie-, Straßen-, Luft- oder Seekarten) eine Zielführung zu einem gewählten Ort oder eine Route unter Beachtung gewünschter Kriterien ermöglicht.
  • Unter einem "Messwert" wird hier der Wert einer Messgröße, der von einem Sensor geliefert wird. Beispiele für Messwerte sind z.B. eine Temperatur in °C, eine Position in Form einer GPS Koordinatenangabe, eine Rotationsgeschwindigkeit in Umdrehung pro Minute etc. "Messwerte" werden auch als "Messdaten" bezeichnet.
  • Unter einer "Datenbank" wird hier eine Datenstruktur zur strukturierten Speicherung von Daten verstanden. Eine Datenbank kann ein Verzeichnisbaum oder eine Datei sein. Vorzugsweise ist eine Datenbank eine von einem Datenbankmanagementsystem (DBMS) verwaltete Datenstruktur. Ein DBMS ist ein System zur elektronischen Datenverwaltung, das dazu ausgebildet ist, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern und benötigte Teilmengen in unterschiedlichen, bedarfsgerechten Darstellungsformen für Benutzer und Anwendungsprogramme bereitzustellen. Zur Abfrage und Verwaltung der Daten bietet ein Datenbanksystem eine Datenbanksprache an. Die Datenbank kann eine relationale Datenbank sein. Die Struktur der Daten wird durch ein Datenbankmodell festgelegt.
  • Unter einer "Historie von Messwerten" wird hier eine Datenmenge verstanden welche den zeitlichen Verlauf mehrerer Messwerte spezifiziert.
  • Unter einem "Zeitstempel" wird hier ein Datenwert verstanden, der einen bestimmten Zeitpunkt spezifiziert, z.B. den Zeitpunkt (Datum und Uhrzeitangabe) wann ein bestimmter Messwert erfasst wurde. Vorzugsweise werden Zeitstempel in der koordinierten Weltzeit UTC angegeben oder mit Bezug zu dieser. Dies kann möglichen Missverständnissen wegen der global unterschiedlichen Zeitzonen vorbeugen.
  • Unter dem Ausdruck "persistent gespeichert" wird hier eine Speicherung von Daten auf einem nicht-volatilen Speichermedium verstanden.
  • Unter dem Ausdruck "geschützt gespeichert" wird hier eine Speicherung von Daten verstanden, welche technisch sicherstellt, dass nur eine bestimmte Auswahl an Nutzern und/oder Applikationen, die sich als zugriffsberechtigt ausweisen kann, auf die geschützten Daten schreibend und/oder lesend zugreifen kann. Beispielsweise kann der Schutz darin bestehen, die Daten in einem zugriffsgeschützten Bereich zu speichern und/oder die Daten verschlüsselt zu speichern, sodass diese nur von einem Programm gelesen werden können, das einen geeigneten Entschlüsselungsschlüssel besitzt
  • Ein "Echtzeitfähiges" System, z.B. ein echtzeitfähiges Automatisierungssystem, ist ein System, das dazu ausgebildet ist, eine Aufgabe in "Echtzeit" durchzuführen. Das bedeutet, dass das System in der Lage ist, diese Aufgabe fortwährend innerhalb einer vordefinierten maximalen Dauer zu erfüllen. Typischerweise bedeutet dies, dass das genannte Hard- und/oder Softwaresystem einer "Echtzeitbeschränkung" unterliegt, z.B. von Ereignis zu Systemreaktion. Echtzeitprogramme müssen die Reaktion innerhalb bestimmter Zeitvorgaben gewährleisten, die oft als "Fristen" bezeichnet werden. Echtzeit-Antworten werden oft in der Größenordnung von Millisekunden und manchmal Mikrosekunden oder Sekunden verstanden. Ein System, das nicht als Echtzeitbetrieb spezifiziert ist, kann in der Regel keine Antwort innerhalb eines Zeitrahmens garantieren, obwohl typische oder erwartete Antwortzeiten angegeben werden können.
  • Unter einem "Host" oder "Host-Computer" wird hier ein Computer verstanden, der allein oder in Interoperation mit einem oder mehreren weiteren Computern ein bestimmtes Softwareprogramm (Gast-Softwareprogramm) bereitstellt, also für weitere Programme und/oder Nutzer verfügbar macht. Bei dem Gastprogramm kann es sich um eine Datenbank, ein Applikationsprogramm, einen Service oder sonstige Programme und Programmodule handeln.
  • Unter einem "Container" wird hier eine Laufzeitumgebung für Softwareprogramme verstanden, welche alle für die Ausführung dieser Softwareprogramme benötigten Systemkomponenten beinhaltet und an diese bereitstellt und welche die innerhalb dieses Containers laufenden Softwareprogramme von Programmen außerhalb des Containers isoliert. Ein Container kann eine virtuelle Maschine sein, die von einem Hypervisor (Programm zur Verwaltung der virtuellen Maschinen) erzeugt und verwaltet werden. Vorzugsweise ist ein Container eine Laufzeitumgebung, die mittels eines Containervirtualisierungsprogramms verwaltet werden kann. Container gemäß diesen Ausführungsformen benötigen typischerweise weniger Ressourcen als virtuelle Maschinen, da sie auf das Starten eines eigenen Betriebssystems verzichten und stattdessen im Kontext des Host-Betriebssystems laufen. Trotzdem sind die Container gegeneinander und vom Host-System abgeschottet, wenn auch nicht so stark, wie bei einer Virtualisierung.
  • Beispielsweise kann die freie Software "Docker" verwendet werden, um Container zu definieren und Anwendungen mittels Containervirtualisierung voneinander zu isolieren. Docker vereinfacht die Bereitstellung von Anwendungen, weil sich Container, die alle nötigen Pakete enthalten, leicht als Dateien transportieren und installieren lassen. Docker packt die Anwendung und alle für deren Ausführung benötigten Systemkomponenten in einer einzigen Datei, den sogenannten "Container". Docker-Container sorgen dafür, dass die Anwendung verlässlich läuft, nachdem sie von einer Umgebung in eine Andere versetzt worden ist. Dies vereinfacht nicht nur das Deployment komplexer Anwendungen auf verschiedenen Computern, sondern auch eine flexiblere Anwendungsinfrastruktur, die sich leichter ändern, erweitern und skalieren lässt.
  • Containervirtualisierung ist eine Methode, um mehrere Instanzen eines Betriebssystems (als sog. "Gäste") isoliert voneinander auf einem Hostsystem zu betreiben. Im Gegensatz zur Virtualisierung mittels eines Hypervisors auf der Basis mehrerer virtueller Maschinen hat Containervirtualisierung zwar einige Einschränkungen in der Art ihrer Gäste, gilt aber als besonders ressourcenschonend. Containervirtualisierung basiert auf mehreren Prinzipien, die in einzelne Softwareprodukten zur Containervirtualisierung unterschiedlich implementiert sind. Ein Kern davon ist jedoch immer ähnlich: mehrere Container nutzen einen Kernel gemeinsam und isolieren zumindest einige der verwendeten Betriebssystemmittel voneinander.
  • Beispielsweise kann das Open-Source-Programm Kubernetes als Containermanagementprogramm verwendet werden. Bei Kubernetes handelt es sich um eine Software zur Container-Orchestrierung, die es ermöglicht, Anwendungen auf einfache und effiziente Weise über mehrere Hosts zu orchestrieren. Kubernetes ermöglicht eine vereinfachtes oder sogar vollautomatisches Deployment, Betrieb, Wartung und Skalierung von Container-basierten Anwendungen. Gruppen von Hosts, auf denen die Container laufen, werden in Clustern von physischen oder virtuellen Maschinen zusammengefasst und als Einheit verwaltet. Kubernetes definiert ein Container Runtime Interface (CRI), das Container-Plattformen implementieren müssen, um mittels Kubernetes orchestriert werden zu können. Diese Implementierungen werden auch als "Shims" bezeichnet. Das macht die Kubernetes Plattformagnostisch: neben bzw. anstelle von Docker können auch andere Plattformen mit entsprechenden Shims, wie z. B. CRI-O oder KataContainers verwendet werden.
  • Unter einer "Containerverwaltungssoftware" wird hier eine Software verstanden, die konfiguriert ist zur automatisierten Bereitstellung, Skalierung und Verwaltung ("Orchestrierung") mehrerer (mindestens zweier) Container auf mehreren Computern auf eine Weise, dass die Computer jeweils als Hostsystem für ein oder mehrere Container dienen, wobei die Container (des gleichen Host-Computersystems wie auch unterschiedlicher Host-Computersysteme) voneinander isoliert sind. Bei den mehreren Containern kann es sich bei komplexen Fahrzeugen um mehrere hundert Container handeln. Beispielsweise kann Kubernetes als Containerverwaltungssoftware verwendet werden.
  • Unter einem "Analysemodul" wird hier eine Software verstanden, die dazu ausgebildet ist, mittels einem oder mehrerer unterschiedlicher rechnerischer Verfahren Messdaten von einem oder mehreren Sensoren so zu verarbeiten, dass eine Antwort auf eine analytische Fragestellung erzeugt wird. Die Software kann ein Skript, ein komplexes Applikationsprogramm, eine Programmbibliothek oder eine Kombination von zwei oder mehreren der vorgenannten Möglichkeiten sein. Das rechentechnische Verfahren kann eine Heuristik, eine von einem Programmierer explizit spezifizierte Regel, ein mathematischer und insbesondere statistischer Algorithmus, z.B. ein Korrelationsanalyseverfahren, oder ein sonstiges explizit formuliertes Rechenverfahren sein. Das rechnerische Verfahren kann auch ein Verfahren sein, welches nur implizit formuliert ist, z.B. in Form des im Zuge eines Trainingsprozesses erstellten mathematischen Modells eines Machine-Learning-Programms. Beispielsweise kann das Modell in der Netzwerkarchitektur und den Gewichten von Netzwerkknoten eines neuronalen Netzwerks spezifiziert sein. Die analytische Fragestellung kann verschiedene Fragen betreffen, z.B. eine Frage nach dem aktuellen oder für die Zukunft vorhergesagten Zustand einer Fahrzeugkomponente (Parameter für Vibration, Leitfähigkeit, Elastizität etc. zeigen kritischen Verschleißzustand an?), oder eine Frage beim Zusammentreffen welcher Messparameterwerte ein kritischer Systemzustand erreicht wurde bzw. in der Zukunft voraussichtlich erreicht wird, die Frage nach der aktuellen und künftigen Verfügbarkeit von Treibstoff oder Verschleißteilen, oder eine Frage nach einer empfohlenen Maßnahme, um einen aktuellen oder künftigen kritischen Zustand des Fahrzeugs oder einer Fahrzeugkomponente zu verhindern oder abzumildern.
  • Unter einer "Verschlüsselungsschlüssel" wird hier ein kryptographischer Schlüssel verstanden, der dazu ausgebildet ist, zur Verschlüsselung von Daten verwendet zu werden. Bei symmetrischen Verfahren, also bei allen klassischen Methoden der Kryptographie und auch bei modernen Algorithmen wie beispielsweise dem Data Encryption Standard (DES) oder seinem Nachfolger, dem Advanced Encryption Standard (AES), verwenden beide Kommunikationspartner denselben (geheimen) Schlüssel sowohl zum Ver- als auch zum Entschlüsseln. Asymmetrische Verfahren, wie beispielsweise das RSA-Kryptosystem, verwenden Schlüsselpaare, die aus einem öffentlichen Schlüssel (englisch public key) und einem privaten Schlüssel (engl. private key, deutsch auch "geheimer Schlüssel") bestehen. Der öffentliche Schlüssel ist nicht geheim, er wird zumindest derjenigen Partei bekannt gegeben, die Daten in verschlüsselter Form an den Inhaber des geheimen Schlüssels senden soll. Mit dem öffentlichen Schlüssel können Daten verschlüsselt. Dabei ist es wichtig, dass ein öffentlicher Schlüssel eindeutig einer bestimmten Entität, z.B. einem Benutzer oder einem Analysemodul, zugeordnet werden kann. Um einen Geheimtext wieder zu entschlüsseln wird der private Schlüssel benötigt. Im Gegensatz zu symmetrischen Verfahren, bei denen sich mehrere Parteien einen geheimen Schlüssel teilen, verfügt bei asymmetrischen Verfahren nur eine Partei über den privaten (geheimen) Schlüssel. Daher ist es grundlegend, dass der private Schlüssel nicht aus dem öffentlichen abgeleitet werden kann.
  • Unter einem "Automatisierungssystem" wird hier ein System zur vollautomatischen oder semiautomatischen Steuerung eines Wasserfahrzeugs verstanden. Die Steuerung erfolgt mittels festgelegten Regeln auf Basis von aktuellen Messwerten von ein oder mehreren Sensoren, die vom Automatisierungssystem in Steuerbefehle umgesetzt werden, und/oder erfolgt auf Basis von Steuerbefehlen, die ein Nutzer über eine Nutzer-Schnittstelle eingibt. Vorzugsweise ist das Automatisierungssystem ein echtzeitfähiges Automatisierungssystem. Gemäß Ausführungsformen der Erfindung ist das Automatisierungssystem dazu ausgebildet, nicht nur aktuelle Messwerte und/oder manuell eingegebene Steuerbefehle als Input zu empfangen und das Fahrzeug entsprechend zu steuern, sondern auch Ergebnisse der Analysen von einem oder mehreren der Analysemodule, wobei das Automatisierungssystem die Ergebnisse als Steuerbefehle interpretiert und umsetzt.
  • Unter einem "Rechnerverbund" oder Computercluster, meist einfach Cluster genannt, wird hier eine Anzahl von vernetzten Computern verstanden. Der Verbund kann so konfiguriert sein, dass die Rechenkapazität und/oder die Verfügbarkeit der Computer oder der von diesen bereitgestellten Dienste erhöht wird. Die in einem Rechnerverbund befindlichen Computer (auch "Knoten") werden auch oft als Server bezeichnet. Gemäß Ausführungsformen der Erfindung hosten die Computer des Rechnerverbunds jeweils ein oder mehrere Container, deren Verteilung auf den Computern von einer Containerverwaltungssoftware orchestriert wird. In den Containern können Analysemodule oder andere Programme ausgeführt werden, die z.B. als Dienst implementiert sein können und deren Ergebnisse an bestimmte Fahrzeugkomponenten bereitgestellt werden können. Aufgrund dieser Bereitstellungsfunktion von Analyseergebnissen können die Computer auch als "Server" bezeichnet werden.
    • Kurze Beschreibung der Zeichnung
  • Nachfolgend werden Ausführungsformen der Erfindung mit Bezug auf die Zeichnung beschrieben. In der Zeichnung zeigt
    • Fig. 1A
    ein Blockdiagramm eines militärischen Wasserfahrzeugs mit mehreren sensorbestückten Fahrzeugkomponenten;
    Fig. 1B
    ein System umfassend mehrere militärische Wasserfahrzeuge und einen Computer mit einer Flottenanalysesoftware;
    Fig. 2
    ein Blockdiagramm eines verteilten Computersystems, das zum Speichern und Analysieren von Sensormessdaten verwendet werden kann;
    Fig. 3
    mehrere analysemodul-spezifische asymmetrische kryptographische Schlüsselpaare und deren Verwendung;
    Fig. 4
    Komponenten eines militärischen Wasserfahrzeugs mit mehreren Datenbanken und Analysemodulen.
  • Figur 1A illustriert ein Blockdiagramm eines militärischen Wasserfahrzeugs 100 mit mehreren sensorbestückten Fahrzeugkomponenten. Beispielsweise umfassen die Fahrzeugkomponenten ein Antriebsystem 104, das z.B. einen mit Diesel betriebenen Schiffsmotor mit einem an den Motor gekoppelten Getriebe beinhaltet. In dem Antriebsystem sind mehrere Sensoren zur Messung verschiedener Parameter des Motors und des Getriebes enthalten, darunter auch ein Sensors 112 für die Drehzahl einer Welle, die mechanisch an das Getriebe gekoppelt ist.
  • Zu den Fahrzeugkomponenten des Wasserfahrzeugs gehört auch ein Navigationssystem 106 mit einem GPS Sensor 114 zur Bestimmung der aktuellen Position des Fahrzeugs sowie ein Ruder 108 mit einem Lage- oder Winkelsensor zur Bestimmung des aktuellen Winkels des Ruders relativ zur Längsachse des Wasserfahrzeugs. Außerdem ist in dem Fahrzeug eine elektronische Überwachungseinheit 110 mit mehreren Sensoren als weitere Fahrzeugkomponente verbaut, die mehrere Sensoren 118, 120 beinhaltet. Die Sensoren der Komponente 110 ermitteln automatisch und vorzugsweise kontinuierlich oder wiederholt Fahrzeugs- und Umgebungsparameterwerde. Zu diesen Parametern gehören z.B. Luftdruck, Luftfeuchtigkeit, Lufttemperatur, Wassertemperatur, Strömungsstärke des Wassers und/oder sonstige Parameter.
  • Alle oder einige der erfassten Parameter werden unmittelbar nach ihrer Erfassung an ein Automatisierungssystem 124 weitergeleitet. Das Automatisierungssystem ist ein vollautomatisches oder semi-automatisches System zur Überwachung und Kontrolle von internen Zuständen des Wasserfahrzeugs sowie zur Steuerung der Bewegung oder sonstiger Aktionen des Fahrzeugs oder seiner Komponenten. Das Automatisierungssystem ist ein Echtzeitsystem, das dazu ausgebildet ist, die von den Sensoren empfangenen Messwerte und Eingaben von Nutzern über eine Nutzeroberfläche zu verwenden um in Abhängigkeit von diesen das Wasserfahrzeug zu steuern.
  • Mit der Zeit fallen so im laufenden Betrieb des Schiffs eine große Anzahl an Messdaten an, die mit einem Zeitstempel versehen werden, welcher die Zeit der Erzeugung der Messdaten widerspiegelt. Die Messdaten und deren Zeitstempel werden in einer Datenbank 122 gespeichert und bilden somit eine Historie der für ein oder mehrere Messparameter erfassten Parameterwerte ab. Bei der Datenbank handelt es sich z.B. um eine relationale Datenbank, z.B. PostgreSQL oder MySQL Datenbank, oder z.B. um eine NoSQL-Datenbank.
  • Die Datenbank sowie mehrere Analysemodule zur Analyse der Daten sind in einem Computersystem 126 gespeichert und instanziiert. Das Computersystem 126 kann ein Standalone-, monolithisches Computersystem sein. Vorzugsweise ist es aber ein Rechnernetz, das mehrere Computer umfasst, die zu einer funktionalen Einheit verbunden sind. Ein solches Rechnernetz ist z.B. im Hinblick auf Figur 2 näher beschrieben.
  • Das Wasserfahrzeug beinhaltet außerdem eine Waffensystem 102, welches ebenfalls Sensoren enthält (nicht gezeigt). Da das Wasserfahrzeug auch aufgrund des Waffensystems als Ziel für gegnerische Kräfte bedeutsam ist und zudem bei einer Fehlsteuerung für die eigene Besatzung als auch für unbeteiligte Dritte eine potentielle Gefahr darstellt, ist ein sicherer Betrieb des Automatisierungssystems von besonders hoher Bedeutung. Ein "sicherer Betrieb" bedeutet hier, dass das Automatisierungssystem wie auch die Daten auf deren Basis es seine Entscheidungen trifft vor Manipulation durch Dritte geschützt sein muss.
    • Beispiel 1: Verbesserte Überwachung und Steuerung einer Ruderanlage
  • Beispielsweise kann es sich bei dem Wasserfahrzeug um ein überseeisches Wasserfahrzeug mit einer Ruderanlage, insbesondere einer Doppelruderanlage handeln. Die Ruderanlage verfügt über ein Steuersystem, das dazu ausgebildet ist, die Lage der Ruder zu überwachen und über ein Verstellsystem zu kontrollieren.
  • Derartige Anlagen werden im Stand der Technik nur gemäß SOLAS (International Convention for the Savety of Life At Sea) und damit nur rudimentär überwacht (Sammelalarm). Für militärische Wasserfahrzeuge ist die Präzision der Überwachung oft nicht ausreichend: Mit den derzeit verfügbaren Doppel-Ruderanlagen kann es vorkommen, dass die Ruder nicht synchron auf Ruderlagen-Steuerbefehle reagieren: Zum Beispiel erreicht das Steuerbord-Ruder eine Ruderlage auf den Steuerbefehl schneller als ein zu diesem korrespondierender Ruderlagen-Steuerbefehl das Backbord-Ruder erreicht. Auch bei Zeitgleichheit des Eintreffens der Befehle kann es sein, dass eine Seite der Ruderanlage den Befehl nicht so schnell umsetzen kann wie die andere Seite. Diese Asynchronität beeinträchtigt die Performance der Ruderplattform und erschwert die präzise Kontrolle weiterer Systemkomponenten, z.B. des Waffensystems. Die Ursachen für eine asynchrone Befehlsweiterleitung und/oder Umsetzung könnten vielfältig sein und auf komplexe Weise zusammenwirken: Unterschiedliche Gleiteigenschaften der Ruderschäfte, alternde Potentiometer in entsprechenden Schaltungen, unterschiedliche Steuerdrücke und vieles mehr.
  • Ausführungsformen der Erfindung begegnen diesem Problem wie folgt: Es wird eine Ruderanlage verwendet, die mit einer Vielzahl von Sensoren für mehrere unterschiedliche ruderanlagenspezifische Parameter, hier als "Ruderanlage-Parameter" bezeichnet, enthält. Zu den Ruderanlage-Parametern gehören zwei oder mehr der folgenden Parameter: Drücke von Ölkreisläufen der Ruderanlage, Spannungen des elektrischen Steuersystems der Ruderanlage, Ströme des elektrischen Steuersystems der Ruderanlage, Position der Ruder und/oder auftretende Beschleunigungen (insbesondere Vibrationen) an den Ruderschäften. Die Sensoren der Ruderanlage sind dazu konfiguriert, regelmäßig innerhalb vergleichsweise kurzer Zeitintervalle (z.B. mindestens einmal pro Minute, vorzugsweise mindestens 10 mal pro Sekunde) eine Messung eines Ruderanlage-Parameters vorzunehmen, diesen Messwert optional zu verschlüsseln und/oder zu signieren und in einer Datenbank in Verknüpfung mit einem Zeitstempel zu speichern. In manchen Ausführungsformen kann die Aufnahmefrequenz des Sensors auch dynamisch an die Gegebenheiten angepasst werden, z.B. Erhöhung der Messfrequenz bei Änderung eines oder mehrerer relevanter Parameter über einen vordefinierten Grenzwert. Der Zeitstempel kann z.B. den Zeitpunkt angeben wann ein Messwert in die Datenbank gespeichert wird, wobei dieser Zeitpunkt sehr nahe am Zeitpunkt der Messwerterfassung liegt und daher auch diesen Zeitpunkt zumindest näherungsweise repräsentiert. Auch die Positionsdaten der Ruder der Ruderanlage werden von Sensoren als "Ruderanlage-Parameter" erfasst, sodass es dem Steuersystem ermöglicht wird, festzustellen, ob die Ruder der Ruderlage die Positionen erreicht haben, die sie gemäß der Steuerbefehle einnehmen sollen.
  • Zusätzlich zu diesen "Ruderanlage-Parameter" erfassen mehrere weitere Sensoren innerhalb oder außerhalb der Ruderanlage Umgebungsparameterwerte, z.B. Geschwindigkeit des Schiffes, Wassertemperatur und/oder Wassertiefe und/oder Betriebszustände weiterer Fahrzeugkomponenten, z.B. eines Pumpsystems. Sollte zum Beispiel die Geschwindigkeit des Schiffes (gemessen z.B. in Metern zurückgelegter Strecke pro Sekunde) nicht zur Verfügung stehen, können alternativ die Antriebsleistung und/oder Turbinendrehzahl als Indikator der Geschwindigkeit verwendet werden.
  • Ausführungsformen erfassen implizit die Zeiten, die eine Ruderanlage benötigt, bis die Ruder bei gegebenen Umweltbedingungen und beim gegebenen Zustand der Ruderanlage die jeweils gegebenen Steuerbefehle umsetzen und die gewünschten Positionen erreicht haben, denn die Messdaten und vorzugsweise auch die Steuerbefehle werden mit Zeitstempeln versehen und in der Datenbank gespeichert. Durch Analyse der Historie dieser Messwerte bzw. Befehle durch ein Analysemodul können somit auf einfache Weise Messwerte und Ruderwerkzustände mit den Zeitpunkten in Bezug gesetzt werden, an welchen das Steuersystem Steuerbefehle an das Stellsystem gesendet hat.
  • Gemäß Ausführungsformen wird ein Analysemodul bereitgestellt, welches anhand der erfassten und in der Datenbank gespeicherten und mit Zeitstempeln verknüpft gespeicherten Messwerte von Ruderanlage-Parametern, Umgebungsparametern und Ruderanlage-Steuerbefehlen die Zeiten ermittelt, bis ein Steuerbefehl unter den jeweils herrschenden Bedingungen vollständig von den durch den Befehl betroffenen Rudern umgesetzt wurde. Die ermittelten Zeiten werden von dem Analysemodul dazu verwendet, das Senden der Steuerbefehle und/oder den Inhalt der Steuerbefehle so anzupassen, dass die Synchronisation der Ruder der Ruderanlage verbessert wird.
  • Nach Ausführungsformen ist das Analysemodul z.B. dazu konfiguriert, Korrelationen zwischen gemessenen Ruderlegezeiten und Wertebereichen von Ruderanlage-Parametern und Umgebungsparametern zu erkennen. Es werden also eine große Menge an Faktoren berücksichtigt, nicht nur eine aktuelle Abweichung der Ruderposition von der Soll-Position, um zu ermitteln, ob und wann ein Ruder eine gewünschte Position einnehmen wird. Möglicherweise auftretende Asynchronitäten zwischen den Rudern auf Backboard-Seite und auf Steuerboard-Seite können so frühzeitig und sicher erkannt werden und es ermöglichen, frühzeitig zu reagieren und die Steuerbefehle an einzelne Ruder schnell und dynamisch, gemäß bevorzugter Ausführungsformen in Echtzeit, anzupassen. Eine Vorhersage von Asynchronitäten erlaubt es außerdem, notwendige Wartungsarbeiten vorherzusagen und erleichtert die diesbezügliche Planung.
  • Das Analysemodul für die verbesserte Steuerung der Ruderanlage kann z.B. anhand der Beschleunigungs- bzw. Vibrationsdaten mögliche Ursachen für Asynchronitäten identifizieren und an einen Nutzer ausgeben. Hierbei werden jedoch nicht nur die Beschleunigungsdaten (Schwingungen/Vibrationen), sondern auch die anderen Ruderanlage-Parameterwerte und Umgebungsparameterwerte in der Analyse berücksichtigt. Dies kann vorteilhaft sein, da auftretende Schwingungen und Vibrationen stark von der Wassertiefe, Ruderlage, Seegang, Bewuchs, Schaltungszuständen der Ruderanlage und von der Schiffsgeschwindigkeit abhängen. Ohne Berücksichtigung des Kontexts sind die Beschleunigungsdaten daher oftmals nicht ausreichend um eine exakte Steuerung der Ruderanlage oder eine exakte Vorhersage des Termins für die nächste nötige Wartung zu ermöglichen. Eine Analyse der Beschleunigungsdaten in Kombination mit den weiteren Ruderanlage-Parametern und Umgebungsparametern ermöglicht es dagegen, Schwingungszustände zu identifizieren, die etwas über die aktuelle Abweichung einer Ruder-Ist-Position von einer Ruder-Soll-Position oder den aktuellen Materialermüdungszustand der Ruderanlage auszusagen.
  • Gemäß einer Ausführungsform der Erfindung umfassen die Fahrzeugkomponenten des Wasserfahrzeugs eine Ruderanlage mit einer Steuereinheit, ein oder mehreren steuerbordseitigen und ein oder mehreren backbordseitigen Rudern. Die Steuereinheit ist dazu ausgebildet, die Lage und Bewegung der steuerbordseitigen und backbordseitigen Ruder durch das Senden von Steuerbefehlen an die steuerbordseitigen Ruder einerseits und an die backbordseitigen Ruder andererseits zu koordinieren, insbesondere zu synchronisieren. Die Ruderanlage beinhaltet mehrere Sensoren, die zur Erfassung von Ruderanlage-Parameterwerten ausgebildet sind, wobei die Ruderanlage-Parameter zwei oder mehr der folgenden Messparameterwerte umfassen: aktuelle Lage der Ruder, Schwingungen der Ruder, Bewuchs der Ruder (z.B. mittels optischem Sensor oder mit Kraftsensor, der die Kraft in Richtung der Anströmung misst), Schwingungen von Komponenten der Ruderanlage, Schaltungszustände der Ruderanlage.
  • Ein oder mehrere der anderen Fahrzeugkomponenten und/oder der Ruderanlage beinhalten zudem mehrere Sensoren, die zur Erfassung von Umgebungs-Parameterwerten ausgebildet sind, wobei die Umgebungs-Parameter zwei oder mehr der folgenden Messparameterwerte umfassen: Wassertiefe, Seegang, Schiffsgeschwindigkeit.
  • Eines der Analysemodule ist ein Analysemodul für die verbesserte Steuerung der Ruderanlage und ist dazu ausgebildet, die Ruderanlage-Parameterwerte, die Umgebungs-Parameterwerte sowie Zeitdauern zwischen einem Senden der Steuerbefehle von der Steuereinheit an die jeweiligen Ruder bis zur Umsetzung der Steuerbefehle zu analysieren, um Korrelationen zwischen den Zeitdauern, den Ruderanlage-Parameterwerten, und den Umgebungs-Parameterwerten zu erkennen und/oder um die Koordination der Ruder der Ruderanlage zu verbessern.
  • Beispielsweise kann das Analysemodul für die verbesserte Steuerung der Ruderanlage dazu ausgebildet sein, automatisch festzustellen, dass bei dem gegebenen Seegang und Bewuchs der Befehl an die steuerbordseitigen Ruder 400 Millisekunden früher gesendet werden muss als der zu diesem korrespondierende Steuerbefehl an die backbordseitigen Ruder. Das Analysemodul sendet ein entsprechendes Kontrollkommando an die Steuereinheit der Ruderanlage und veranlasst hierdurch die Steuereinheit, den Befehl an die steuerbordseitigen Ruder erst nach der besagten Verzögerung an die backbordseitigen Ruder zu senden.
  • Gemäß Ausführungsformen der Erfindung ist das Analysemodul für die verbesserte Steuerung der Ruderanlage dazu ausgebildet, die Ruderanlage-Parameterwerte, die Umgebungs-Parameterwerte, die Zeitdauern zwischen einem Senden der Steuerbefehle von der Steuereinheit an die jeweiligen Ruder bis zur Umsetzung der Steuerbefehle und zusätzlich Zustands- und/oder Vibrationsparameterwerte zu analysieren, die von Sensoren anderer Fahrzeugkomponenten, insbesondere des Motors und/oder des Getriebes und/oder einer Radaranlage, erfasst wurden, um Korrelationen zwischen den Zeitdauern, den Ruderanlage-Parameterwerten, den Umgebungs-Parameterwerten und den Zustands- und/oder Vibrationsparameterwerten der anderen Fahrzeugkomponenten zu erkennen und/oder um die Koordination der Ruder der Ruderanlage zu verbessern.
  • Diesen Merkmalen liegt die Beobachtung zu Grunde, dass auch Fahrzeugkomponenten das Verhalten und die Steuerbarkeit der Ruderanlage beeinflussen können, die nicht einem explizit steuernden Zusammenhang mit der Ruderanlage stehen. So könnte z. B. eine Radaranlage durch die von einem Antriebs-Dieselmotor bei einer bestimmten Geschwindigkeit erzeugte Frequenz angeregt werden, die zu einer negativen Beeinflussung der Ruderanlage führt.
  • Beispielsweise kann die Steuerung in Form von Logik-Regeln implementiert sein. Diese Regeln können neben der hier beschriebenen Steuerung der Ruderanlage auch zur Steuerung anderer Wasserfahrzeugkomponenten verwendet werden. Beispielsweise kann eine der Logikregeln beinhalten, dass ein Verbrennungsmotor sich nur starten lässt, wenn mindestens ein Abgasweg geöffnet ist. Bei jedem Startvorgang dieses Motors wird diese Regel ausgeführt und je nach Ergebnis der Prüfung ob ein Abgasweg offen ist entweder ein solcher Abgasweg automatisch geöffnet oder der Startvorgang - ggf. begleitet von einer Meldung an den Nutzer - abgebrochen.
    • Beispiel 2: Verbesserte Erkennung und Vorhersage von Verbrauch und Zuständen
  • Umgebungsparameter und zustandsbezogene Parameter von Fahrzeugkomponenten hängen in komplexer Weise voneinander ab.
  • Wenn beispielsweise die Seewassertemperatur höher ist, arbeiten die Kühlsysteme, die Seewasser zur Kühlung verwenden, anders als bei kaltem Seewasser. Die Stromaufnahme erhöht sich und die für die Stromerzeugung verwendeten Dieselmotoren werden stärker belastet. Dies hat dann wiederum Auswirkungen auf Wartung und Verschleiß der Aggregate, die durch eine höhere Seewassertemperatur nicht nur höher belastet werden, weil mehr Energie für die Kühlung verwendet werden muss, sondern zusätzlich schlechter ihre eigene Kühlung realisieren können, da die Maschinen und Kapseln in der Regel ebenso mit Seewasser gekühlt werden wie der Motor selbst. Die Leistungskennwerte von seewassergekühlten Fahrzeugkomponenten sind daher oftmals schlecht vergleichbar und die Vorhersagen bezüglich ihres Energieverbrauchs mit Unsicherheiten behaftet.
  • Gemäß Ausführungsformen der Erfindung ist eines der Analysemodule dazu konfiguriert, den aktuellen oder künftigen Energieverbrauch und/oder den aktuellen oder künftigen Verschleißgrad einer Fahrzeugkomponente in Abhängigkeit von der Temperatur des als Kühlwasser verwendeten Umgebungswassers zu berechnen.
  • Mit dieser Datengrundlage können z.B. auch automatisch gleichartige Betriebsmodi des gesamten Wasserfahrzeugs gefunden werden, z.B. Betriebsmodi, die durch die Temperatur des Umgebungswassers definiert sind, um die Bewertung von Messdaten und/oder sonstiger Leistungsparameter des ganzen Wasserfahrzeugs so zu berücksichtigen, dass nur vergleichbare Betriebsmodi des Fahrzeugs miteinander verglichen werden.
  • Nach Ausführungsformen ist das eine Analysemodul dazu konfiguriert, die zu verschiedenen Zeitpunkten gemessene Temperatur dazu zu verwenden, auch automatisch gleichartige Betriebsmodi des gesamten Wasserfahrzeugs zu identifizieren, die durch eine bestimmte Temperatur oder einen bestimmten Temperaturbereich des Umgebungswassers definiert sind. Das Analysemodul ist dazu konfiguriert, Messdaten und/oder sonstige Leistungsparameter des ganzen Wasserfahrzeugs so zu analysieren, dass nur vergleichbare Betriebsmodi des Fahrzeugs miteinander verglichen werden, um insbesondere den künftigen Energieverbrauch, die aktuell maximal mögliche Reichweite und/oder den aktuellen oder künftigen Verschleißgrad zu berechnen.
  • Weiterhin können durch Analyse von Leistungs- und Zustandsmesswerten, die von Sensoren einer Vielzahl von Fahrzeugkomponenten erfasst und in der Datenbank gespeichert wurden sowie durch Erfassung und Analyse der Nutzungsprofile der einzelnen Fahrzeugkomponenten (die z.B. spezifizieren, wie oft welche ggf. redundanten Fahrzeugkomponenten bei welchen Situationen verwendet werden und/oder wie hoch die Auslastung verschiedener Fahrzeugkomponenten bei unterschiedlichen Bereitschafts- und Nutzungszuständen ist) kann sowohl die Inbetriebnahmeals auch die Nutzungsphase verschiedener Fahrzeugkomponenten verbessert werden. Diese Erkenntnisse können es ermöglichen, automatisch oder manuell die Betriebsmodi einzelner Fahrzeugkomponenten zu optimieren oder die technischen Eigenschaften einer (neuen) Fahrzeugkomponente zu verbessen.
    • Beispiel 3: Fahrzeuqübergreifende Analysen
  • Die Erfassung und Speicherung einer Vielzahl an Messwerten über längere Zeiträume hinweg (Messwerthistorie) gemäß Ausführungsformen der Erfindung hat bereits auf der Anwendungsebene erhebliche Vorteile.
  • Weitere erhebliche Vorteile ergeben sich für Systeme, gemäß welchen die Messwert-Historien mehrerer Parameter, die von mehreren Wasserfahrzeugen erfasst wurden, durch eine Flottenanalysesoftware analysiert wird. Beispielsweise kann zumindest für die Ruderanlage der Fahrzeuge ein Erfassungssystem und Analysemodul entwickelt wurden sein wie für Beispiel 1 beschrieben. Die Ruderanlagen der verschiedenen Fahrzeuge können, müssten aber nicht, typgleich sein (also z.B. vom gleichen Hersteller stammen). Denn selbst falls sich die Ruderanlagen leicht unterscheiden, können zumindest Subsysteme wie z.B. die einzelnen Sensoren der Ruderanlage oder die Steuereinheit typgleich oder vergleichbar sein. Oftmals verwenden verschiedene Hersteller von bestimmten Fahrzeugkomponenten die gleichen, von einem Zulieferer gestellten Bauteile.
  • Durch Import der Datenbanken mit den Messwert-Historien mehrerer Wasserfahrzeuge in eine zentrale und besonders geschützte Datenbank, z.B. innerhalb der sicheren Infrastruktur eines Heimathafens, können also plattformübergreifende Auswertungen vorgenommen werden. Beispielsweise kann zumindest ein Teil der historischen Daten im Zuge des Aufenthalts eines Wasserfahrzeugs im Heimathafen in die zentrale Datenbank importiert und von der Datenbank des Wasserfahrzeugs gelöscht werden. Dies erhöht die Datensicherheit und reduziert den Speicherbedarf der Datenbank des Wasserfahrzeugs.
  • Die verschiedenen Datensätze können mehrfach dienlich sein. Die Flottenanalysesoftware kann z.B. durch Analyse verschiedener Umgebungsparameter wie Luft- und Wassertemperatur, Strömungsverhältnissen etc. feststellen ob die Fahrzeuge bzw. Fahrzeugkomponenten unter vergleichbaren Bedingungen betrieben wurden bzw. solche Fahrzeuge und Komponenten identifizieren, die unter vergleichbaren, d.h., hinreichend ähnlichen, Bedingungen betrieben wurden. Im nächsten Schritt kann die Flottenanalysesoftware dann analysieren und erkennen, ob Fahrzeugkomponenten eines bestimmten Typs oder Herstellers im Hinblick auf ein oder mehrere Leistungsparameter besser oder schlechter sind als funktionsgleiche Fahrzeugkomponenten eines anderen Typs oder eines anderen Herstellers. So kann ein bereits aufgetretenes Problem auf der einen Fahrzeugkomponente ggf. auf einer anderen verhindert werden. Weiterhin kann Fahrzeugübergreifend festgestellt werden, wie eine bestimmte Fahrzeugkomponente besser betrieben werden kann oder eben nicht betrieben werden soll, um bestimmte Schäden zu vermeiden.
  • Die von der Flottenanalysesoftware berechneten Handlungsempfehlungen können an einen Nutzer ausgegeben werden um diesen dazu zu veranlassen, Verbesserungen für eine bestimmte Fahrzeugkomponenten sowie typgleiche oder typähnliche Komponenten vorzunehmen. Gemäß manchen Ausführungsformen können einzelne Analysemodule und/oder die Flottenanalysesoftware dazu konfiguriert sein, auch taktische Empfehlungen aufgrund der Daten der Datenbank(en) zu berechnen und auszugeben.
  • Figur 1B zeigt ein System 150 mit mehreren militärische Wasserfahrzeugen 100, 130, 132. Jedes der Wasserfahrzeuge kann ausgebildet sein als ein Wasserfahrzeug der hier beschriebenen Ausführungsformen. Vorzugsweise gehören die Wasserfahrzeuge alle zum gleichen oder zu einem ähnlichen Fahrzeugtyp. Es ist jedoch auch möglich, dass die Wasserfahrzeuge zu unterschiedlichen Fahrzeugtypen gehören, auch in diesem Fall kann eine Auswertung der Sensordatenhistorien für mehrere Wasserfahrzeuge vorteilhaft sein, z.B. wenn die Fahrzeuge unterschiedlichen Typs einige oder mehrere Fahrzeugkomponenten des gleichen Typs beinhalten, sodass ein Vergleich der komponentenbezogenen Messwerte zumindest für diese Fahrzeugkomponenten sinnvoll ist.
  • Das System 150 beinhalten außerdem ein Computersystem 134, das z.B. als einzelner Rechner oder Rechnerverbund ausgebildet sein kann. Das Computersystem beinhaltet eine Schnittstelle 136 zum sicheren Import des Inhalts der Datenbanken der Wasserfahrzeuge 100, 130, 132. Je nach Implementierungsvariante kann die Schnittstelle 136 unterschiedlich implementiert sein. Es kann sich z.B. über eine kabelgebundene Schnittstelle handeln, z.B. auf Basis der Glasfasertechnologie, die eine rasche Übertragung von großen Datenmengen zulässt. In manchen Fällen kann es sich aber auch um eine kontaktlose Schnittstelle handeln, z.B. über eine Schnittstelle einer Funkverbindung, oder um eine USB-Schnittstelle zum Import von Daten auf einem portablen Laufwerk über USB. In jedem Fall sind mehrere technische und/oder organisatorische Sicherheitsvorkehrungen getroffen, um sicherzustellen, dass die Daten während der Übertragung nicht ausgelesen oder manipuliert werden können. Beispielsweise kann die Übertragung nur verschlüsselt über einen Ende-zu-Ende verschlüsselten Datenübertragungskanal erfolgen. Oder es kann eine Authentifizierung des die Datenübertragung veranlassenden Nutzers erforderlich sein, z.B. über passwortbasierte und/oder biometrische Authentifizierungsverfahren. Beispielsweise kann das Computersystem 134 und die Schnittstelle 136 zur sicheren Datenübertragung Bestandteil der IT-Infrastruktur eines Heimathafens sein, die dazu genutzt werden kann, die von den Wasserfahrzeugen während ihrer Einsätze automatisch erzeugten Messdaten zu importieren und gesammelt auszuwerten.
  • Die Auswertung der Daten mehrerer Wasserfahrzeuge wird von einer Flottenanalysesoftware 138 durchgeführt, die auf dem Computersystem 134 instanziiert ist. Die Flottenanalysesoftware analysiert die importierten Messwerte der Datenbanken der Wasserfahrzeugen. Die importierten Daten können z.B. in einer zentralen relationalen Datenbank auf dem Computersystem 134 gespeichert und dort analysiert werden. Die Flottenanalysesoftware erkennt im Zuge der Analyse automatisch, ob die Messwerte unterschiedlicher Wasserfahrzuge von Fahrzeugkomponenten gleichen Typs erfasst wurden. Diese Information kann hilfreich sein um sicherzustellen, dass die richtigen Messwerte verglichen werden. Ein Temperatursensor eines Motors misst die Motortemperatur, ein Temperatursensor an der Außenseite des Fahrzeugs unterhalb des Wasserspiegels misst die Wassertemperatur. Es ist wichtig, bei der Analyse zu berücksichtigen, von welchem Sensor bzw. von welcher Fahrzeugkomponente ein Parameterwert "Temperatur" stammt, denn ein Vergleich ist in der Regel nur dann sinnvoll, wenn die Messwerte von Sensoren und Komponenten gleichen oder ähnlichen Typs stammen, also z.B. nur die Temperaturwerte für die Komponente "Motor" miteinander verglichen werden. Vorzugsweise wird auch der Hersteller bei der Analyse miteinbezogen. Es kann z.B. sein, dass unterschiedliche Hersteller des gleichen Typs von Fahrzeugkomponente (Motor) den Sensor an leicht unterschiedlichen Positionen anbringen oder unterschiedliche Sensortypen verwenden. In diesem Fall kann die Berücksichtigung der unterschiedlichen Hersteller bzw. sonstiger relevanter Umstände dazu beitragen, falsche Analyseergebnisse aufgrund einer fehlerhaften Interpretation kleinerer herstellerbedingter Messwertabweichungen erzeugt werden.
  • Im Zuge der Analyse erkennt die Flottenanalysesoftware dasjenige der Wasserfahrzeuge anhand der importierten Messdaten, welches oder welche der Wasserfahrzeuge im Hinblick auf zumindest ein bestimmtes Zielkriterium optimal oder am schlechtesten beschaffen sind. Bei dem Zielkriterium handelt es sich um ein technisches Bewertungskriterium wie z.B. dasjenige Fahrzeug mit dem besten Füllstand von Energie und Verschleißteilreserven, dasjenige Fahrzeug mit dem geringsten Wartungsstau und/oder mit der längsten Zeit bis zur Fälligkeit der nächsten Inspektion. Zusätzlich oder alternativ dazu erkennt die Flottenanalysesoftware kritische Zustände von Fahrzeugkomponenten in einem oder mehreren der Wasserfahrzeuge. Beispielsweise kann die Flottenanalysesoftware all diejenigen Fahrzeuge identifizieren, in welchen Vibrationsparameter darauf hindeuten, dass innerhalb der letzten 6 Monate in einem Motor z.B. aufgrund von Materialermüdung oder anderer ungünstiger Faktoren Temperaturen und/oder Drehzahlwerte gemessen wurden, die als gefährlich für die Fahrzeugkomponente und/oder die Besatzung angesehen werden muss.
  • In manchen Ausführungsformen ist die Flottenanalysesoftware dazu ausgebildet, den Zeitpunkt des Eintretens eines kritischen Zustands einer Fahrzeugkomponente in einem oder mehreren der Wasserfahrzeuge vorherzusagen. Das könnte der Zeitpunkt sein, an welchem Energie-, Sauerstoffgas-, oder Lebensmittelvorräte zur Neige gehen, an welchem mit einem Versagen eines essentiellen Bauteils aufgrund von Verschleiß zu rechnen ist oder dergleichen.
  • In manchen Ausführungsformen ist die Flottenanalysesoftware außerdem dazu ausgebildet, automatisch ein oder mehrere Umgebungs-Parameter und/oder Fahrzeugkomponenten-Parameter und deren entsprechende Parameterwertebereiche zu identifizieren, die ursächlich für einen kritischen Zustand einer der Fahrzeugkomponenten in einem oder mehreren der Wasserfahrzeuge sind. Dies ist ein besonders vorteilhafter Aspekt gerade im Kontext hoch komplexer militärischer Wasserfahrzeuge: bisweilen sind Fahrzeugkomponenten und Bauteile schon deutlich vor dem erwarteten, normalen Lebenszeitende defekt, ohne dass hierfür eine eindeutige Ursache zu erkennen ist. Bisweilen ist auch zu beobachten, dass ein bestimmtes Bauteil in einem bestimmten Wasserfahrzeug immer wieder versagt während das gleiche Bauteil in anderen Wasserfahrzeugen des gleichen Typs und mit den gleichen Komponenten deutlich länger hält. Angesichts des hochkomplexen Zusammenwirkens verschiedener Bauteile und Umweltfaktoren wird regelmäßig vermutet, dass die Ursache des Problems in einer Wechselwirkung des Bauteils mit seiner Umgebung besteht, wobei nicht genau bekannt ist, welche Ursache konkret für das Versagen des Bauteils verantwortlich ist. Die mechanischen Belastungen von Bauteilen hängen von verschiedensten Faktoren ab, zum Beispiel dem Vibrationsverhalten räumlich benachbarter Bauteile, dem Seegang, Wind und Strömungsbedingungen denen das Fahrzeug im Rahmen seines Einsatzes ausgesetzt ist und nicht zuletzt auch von manuell eingegebenen Steuerbefehlen der Besatzung. Angesichts dieser Komplexität ist es oft nicht möglich, konkrete Ursachen für den Ausfall von Komponenten durch genaue Inspektion eines bestimmten Fahrzeugs zu identifizieren. Erst durch eine Analyse einer Vielzahl von Messwerten, die über einen längeren Zeitraum von den Sensoren einer Vielzahl von Wasserfahrzeugen erfasst und gespeichert wurden, ist es möglich, den Ausfall bestimmter Bauteile mit dem Zusammenwirken mehrerer anderer Faktoren zu korrelieren, zum Beispiel einer bestimmten Fahrweise, einer bestimmten Lufttemperatur, eines bestimmten Salzgehalts, bestimmten Strömungsverhältnissen und der Verwendung bestimmter weiterer Bauteile und Fahrzeugkomponenten anderer Hersteller. Somit ermöglicht die Flottendiagnose eine verbesserte Fehlerdiagnose aufgrund einer breiteren Datenbasis einschließlich der Erkennung von Fehlern, die in höchst komplexer, oftmals nichtlinearer Weise durch Zusammenwirken mehrerer spezifischer Faktoren verursacht werden.
  • Figur 2 zeigt ein Blockdiagramm eines verteilten Computersystems 126, das zum Speichern und Analysieren von Sensormessdaten verwendet werden kann. Das hier gezeigte Computersystem beinhaltet 5 Computer 202, 204, 206, 208, die funktional über ein Netzwerk 280, zum Beispiel ein Intranet, zu einem Rechnerverbund miteinander verbunden sind und auf welchen jeweils mehrere Container 212-230 instanziiert sind. Jede der Computer verfügt über ein oder mehrere Prozessoren 240, 242, 244, 246, Arbeitsspeicher 248, 250, 252, 254 sowie optional auch über ein oder mehrere nicht-flüchtige Datenspeicher.
  • In jedem der Container ist maximal eine Instanz eines Analysemoduls enthalten und wird dort ausgeführt. Beispielsweise können die Analysemodule jeweils als sogenannter Mikroservice implementiert sein.
  • Einige Analysemodule sind nur in einer einzigen Instanz vertreten. Beispielsweise läuft Analysemodul AM2 nur in Form einer einzigen Instanz 262 innerhalb des Containers 214, das Analysemodul AM3 nur in Form einer einzigen Instanz 264 in Container 216, und Analysemodul AM4 nur in Form einer einzigen Instanz 268 in Container 222. Manche Analysemodule können aber auch in mehreren Instanzen innerhalb einer entsprechenden Anzahl an Containern ausgeführt werden. Beispielsweise ist Analysemodul AM1 in Form der beiden Instanzen 260, 266 in den Containern 212 bzw. 220 instanziiert.
  • Wie viele Instanzen der einzelnen Analysemodule instanziiert und/oder geschlossen werden und auf welchem der Rechner dies geschieht wird von der Containerverwaltungssoftware 256 gesteuert. Die Software 256 orchestriert die Instanziierung, Migration und Schließung von Containern und darin enthaltenen Analysemodulen dynamisch nach verschiedenen Optimierungskriterien, die vorzugsweise von einem Nutzer konfigurierbar sind. Optimierungskriterien können zum Beispiel Load-Balancing, Upscaling und Downscaling Kriterien sein, die dafür sorgen, dass die Rechenlast ausgewogen unter den Computern verteilt ist, manche häufig benötigte Analysemodule parallel in mehreren Instanzen ausgeführt werden können, eine schnelle Antwortzeit und/oder hohe Ausfallsicherheit gewährleistet wird.
  • Die von den Sensoren der verschiedenen Fahrzeugkomponenten des Wasserfahrzeugs 100 erfassten Messdaten werden in einer Datenbank 122 gespeichert. Um die Ausfallsicherheit der Datenbank zu erhöhen werden die Inhalte der Datenbank in redundanter Weise auf den verschiedenen Computern 202-208 verteilt gespeichert. Im Stand der Technik sind verschiedene Verfahren zur verteilten, redundanten Speicherung von Daten bekannt, zum Beispiel die Speicherung mittels Fehlerkorrekturverfahren unter Verwendung von Fehlerkorrekturbits. In manchen Ausführungsformen können einige der Container 224-230 auch zur Speicherung von Teilen der Daten der Datenbank verwendet werden.
  • Das Automatisierungssystem 124 beinhaltet ebenfalls ein oder mehrere Prozessoren 282, Arbeitsspeicher 284 und eine Automatisierungssoftware 286. Die Automatisierungssoftware ist dazu konfiguriert, aktuell erfasste Messdaten von zumindest einigen der Sensoren dynamisch zu empfangen und diese, gegebenenfalls zusammen mit von einem Nutzer eingegebenen Befehlen, als Input zu verwenden, um ein oder mehrere Steuerbefehle aus diesem Input abzuleiten und auf Basis der Steuerbefehle das Verhalten der ein oder mehreren Fahrzeugkomponenten 102, 104, 106, 108, 110 automatisch zu steuern.
  • Das Computersystem 290 mit dem Automatisierungssystem 124 ist über einen Datenkommunikationskanal 292 mit dem Rechnerverbund 126 verbunden. In manchen Ausführungsformen kann das Automatisierungssystem über die Datenverbindung 292 eine Anfrage an einen Zugriffsdienst 288 senden, um über diesen Daten aus der verteilt gespeicherten Datenbank 122 zu lesen und für die Berechnung von Steuerbefehlen zu verwenden. Das Automatisierungssystem ist operativ entkoppelt von den Analysemodulen, das heißt, es läuft vorzugsweise auf einem anderen Computer und greift, sofern es die in der Datenbank gespeicherten Messwerte nutzt, asynchron zu den Analysemodulen auf die Messwerte zu.
  • Figur 3 zeigt mehrere analysemodul-spezifische asymmetrische kryptographische Schlüsselpaare die zur sicheren Übertragung und Speicherung von Messdaten verwendet werden können.
  • Beispielsweise kann das Antriebssystem 104 von einem ersten Hersteller H1 hergestellt werden. Der Hersteller H1 entwickelt außerdem ein Analysemodul AM4, dass dazu ausgebildet ist, Messwerte, die von einem oder mehreren Sensoren 112 des Antriebs erfasst werden, zu analysieren, um automatisch den aktuellen und/oder künftigen Zustand des Antriebssystems 104 vorherzusagen. Vor oder im Zuge der Entwicklung des Analysemoduls AM4 erzeugt der Hersteller H1 ein erstes asymmetrisches kryptographisches Schlüsselpaar mit einem ersten geheimen Entschlüsselungsschlüssel 344 und einem dazu korrespondierenden öffentlichen Verschlüsselungsschlüssel 332. Vor Auslieferung des Analysemoduls AM4 an den Betreiber oder Hersteller des militärischen Wasserfahrzeugs 100 wird der geheime kryptographische Entschlüsselungsschlüssel 344 so in dem Analysemodul AM4 integriert, dass er nicht von unberechtigten Dritten ausgelesen werden kann. Außerdem wird der Drehzahlsensor 112 des Antriebssystems 104 mit dem öffentlichen Verschlüsselungsschlüssel 332 versehen.
  • Die öffentlichen Schlüssel, hier sämtlich mit dicken Umrisslinien dargestellt, können zusammen mit ihren jeweils korrespondierenden privaten Schlüsseln für jeden einzelnen Sensor einer Fahrzeugkomponente spezifisch erstellt werden. In anderen Ausführungsformen ist es jedoch auch möglich, dass sich alle Sensoren einer Fahrzeugkomponente das gleiche kryptographische Schlüsselpaar bzw. den öffentlichen Schlüssel dieses Paares teilen und den öffentlichen Schlüssel dazu verwenden, die von den Sensoren jeweils erfassten Messdaten zu verschlüsseln. Eine sensorindividuelle Erzeugung von Schlüsselpaaren hat den Vorteil einer sehr feingranularen Steuerung der Zugriffsrechte. Eine fahrzeugkomponenten-individuelle Erzeugung von Schlüsselpaaren und die Verwendung des gleichen öffentlichen Schlüssels durch die Sensoren der gleichen Fahrzeugkomponente hat den Vorteil der vereinfachten Schlüsselverwaltung, denn in der Regel, wenn auch nicht immer, haben die von verschiedenen Sensoren eines Fahrzeugs erfassten Messdaten identische oder ähnliche Anforderungen an deren Geheimhaltung.
  • Alle Messwerte, die der Sensor 112 erfasst, um diese in der Datenbank 122 zu speichern, werden mit dem öffentlichen Schlüssel 332 verschlüsselt. Das bedeutet, dass alle anderen Analysemodule AM1, AM2 und AM3 die von dem Drehzahlsensor 112 erfassten und mit dem Schlüssel 332 verschlüsselten Daten nicht entschlüsseln können.
  • In einer Ausführungsform ist der Drehzahlsensor 112 allerdings dazu konfiguriert, Kopien der von ihm erfassten Messwerte mit einem öffentlichen Schlüssel 330, der einem Analysemodul AM3 eines anderen Herstellers H2 zugewiesen ist, zu verschlüsseln, sodass dieses Analysemodule AM3 die Kopien mit seinem korrespondierenden privaten kryptographischen Schlüssel 342 entschlüsseln kann. Beispielsweise können vertragliche Vertrauensbeziehungen zwischen Hersteller H1 und Hersteller H2 des Ruders 108 bestehen, sodass der Sensor 112 des Antriebssystems die von ihm erfassten Messwerte nicht nur mit dem öffentlichen Schlüssel 332, sondern in Kopie auch mit dem öffentlichen Schlüssel 330 verschlüsselt, sodass nicht nur Analysemodul AM4 sondern auch Analysemodul AM3 auf diese Messwerte zugreifen und entschlüsseln kann.
  • In analoger Weise kann die Fahrzeugkomponente 110, die einen Temperatursensor 120 und einen Drucksensor 118 beinhaltet, von einem dritten Hersteller H3 hergestellt werden. Der Hersteller H3 entwickelt außerdem die Analysemodule AM5 und AM6, die in mehreren Kopien auf dem Computersystem 126 instanziiert sein können. Module AM5 und AM6 werten beide jeweils sowohl Temperaturdaten als auch Druckdaten aus, allerdings im Hinblick auf unterschiedliche Analysezwecke bzw. Fragestellungen. Der Sensor 120 erzeugt seine Messdaten in Form von zwei Kopien von Messdaten, die mit unterschiedlichen öffentlichen Schlüsseln 324, 322 verschlüsselt sind. Auch der Sensor 118 erzeugt seine Messdaten in Form von zwei Kopien von Messdaten, die mit den öffentlichen Schlüsseln 324, 322 verschlüsselt sind. Daten, die mit dem Schlüssel 322 verschlüsselt wurden können von jedem Analysemodul, das den zugehörigen privaten Schlüssel 334 enthält, entschlüsselt und verarbeitet werden. Daten, die mit dem Schlüssel 324 verschlüsselt wurden können von jedem Analysemodul, das den zugehörigen privaten Schlüssel 336 enthält, entschlüsselt und verarbeitet werden. Jede der mehreren Instanzen 306-312 des Analysemoduls AM5 beinhaltet den privaten Schlüssel 334. Jede der mehreren Instanzen 314-318 des Analysemoduls AM6 beinhaltet den privaten Schlüssel 336.
  • Das Ruder 108 beinhaltet in dem dargestellten Beispiel drei Sensoren unterschiedlichen Typs, darunter der Winkelsensor 114. Jedem der Sensoren ist ein öffentlicher Schlüssel 326-330 zugeordnet, der mit einem korrespondierenden privaten Schlüssel 338-342 ein asymmetrisches kryptographisches Schlüsselpaar bildet. Die von den Sensoren erfassten Messwerte werden in dreifacher Kopie verschlüsselt jeweils mit einem anderen der öffentlichen Schlüssel in die Datenbank gespeichert. Analysemoduls AM1 kann nur diejenigen Daten entschlüsseln, die mit dem öffentlichen Schlüssel 326 verschlüsselt wurden. Analysemoduls AM2 kann nur diejenigen Daten entschlüsseln, die mit dem öffentlichen Schlüssel 328 verschlüsselt wurden. Analysemoduls AM3 besitzt allerdings zwei private Schlüssel 340, 342 und kann daher Daten entschlüsseln, die mit dem öffentlichen Schlüssel 328 oder mit dem öffentlichen Schlüssel 330 verschlüsselt wurden.
  • Diese genaue Kontrolle von Zugriffsrechten ist gerade im Bereich militärischer Wasserfahrzeuge sehr vorteilhaft, denn oftmals ist erst eine Kombination bestimmter Daten sicherheitskritisch, nicht einzelne Datenwerte. Beispielsweise sind GPS Positionsdaten in jedem Fall sicherheitskritisch, denn sie erlauben es gegnerischen Einheiten, einen Angriff auf das Wasserfahrzeug einzuleiten. Die Position des Wasserfahrzeugs unterhalb des Wasserspiegels (falls es sich um ein U-Boot handelt) ist allein in der Regel nicht kritisch, sofern keine weiteren Positionsdaten bekannt sind. Gleiches gilt für Daten wie Wassertemperatur oder Strömungsverhältnisse. Allerdings erlaubt eine Kombination der Position des Wasserfahrzeugs unter Wasser mit Strömungs- und Temperaturdaten in manchen Fällen eine zumindest ungefähre Bestimmung der aktuellen Position des Wasserfahrzeugs.
  • Die Verwendung verschiedener Verschlüsselungsschlüssel für verschiedene Arten von Messdaten gemäß Ausführungsformen der Erfindung erlaubt eine feingranulare Kontrolle des Zugriffs auf diese Messdaten. Analysemodule haben nur einen oder nur einige wenige private Schlüssel und können somit nur auf diejenigen Messdaten zugreifen und diese verarbeiten, die von einem Sensor erfasst wurden, der einen zu diesen privaten Schlüssel korrespondierenden öffentlichen Schlüssel zur Verschlüsselung verwendet hat.
  • Nach Ausführungsformen verfügt eine einzelne besonders vertrauenswürdige Software über eine Kopie aller privaten Schlüssel der Analysemodule. Beispielsweise kann die besonders vertrauenswürdige Software ein weiteres Analysemodul mit erweiterter Berechtigung sein, das vom Betreiber des Fahrzeugs entwickelt wurde. Zusätzlich oder alternativ dazu kann die Flottenanalysesoftware über eine Kopie aller privaten Schlüssel der Analysemodule verfügen, um die Daten aller Sensoren aller Wasserfahrzeuge einer Flotte analysieren zu können.
  • Figur 3 zeigt die Zuweisung von privaten Entschlüsselungsschlüsseln an die einzelnen Analysemodule und die Zuweisung von öffentlichen Verschlüsselungsschlüssel an die Sensoren (oder diese Sensoren enthaltenden Fahrzeugkomponenten). Die Sensoren erheben Messdaten und verschlüsseln diese mit den ihnen zugewiesenen öffentlichen Schlüsseln.
  • Gemäß Ausführungsformen der Erfindung werden weitere asymmetrische kryptographische Schlüsselpaare den Sensoren und Analysemodulen zugeiwesen, allerdings zum Zwecke der Signaturprüfung (hier nicht dargestellt). In diesem Fall werden private Signierschlüssel den einzelnen Sensoren oder den diese Sensoren beinhaltenden Fahrzeugkomponenten zugewiesen. Die Sensoren oder Fahrzeugkomponenten verwenden die Signierschlüssel, um die erfassten und optional verschlüsselten Messdaten zu signieren. Die einzelnen Analysemodule haben Zugriff auf öffentliche Signaturprüfschlüssel, die jeweils mit einem der Signierschlüssel ein asymmetrisches kryptographisches Schlüsselpaar bilden. Beispielsweise können die öffentlichen Signaturprüfschlüssel Bestandteil einzelner Analysemodule sein. Die Analysemodule sind dazu konfiguriert, die Validität der Signaturen der Messdaten mit Signaturprüfschlüsseln zu prüfen, und die Messdaten nur dann weiterzuverarbeiten wenn deren Signatur valide ist.
  • Figur 4 zeigt beispielhaft einige Komponenten eines militärischen Wasserfahrzeug mit mehreren Analysemodulen ("AMs") und einer Datenbank 122. Die Datenbank 122 ist hier in Form von zwei unterschiedlichen Datenbanken realisiert, die jeweils unterschiedliche Teile der Daten beinhalten. Datenbank 122.1 enthält Messdaten mit einem normalen Sicherheitsniveau, die ganz oder in Teilen in unverschlüsselter Form vorliegen. Datenbank 122.2 dagegen beinhaltet sensible Messdaten, die im militärischen Bereich auch als "rote Daten" bezeichnet werden, und die vorzugsweise mit einem oder mehreren verschiedenen kryptographischen Schlüsseln verschlüsselt sind, z.B. gemäß eines im Hinblick auf Figur 3 beschriebenen Verschlüsselungsverfahrens. Die Box 406 repräsentiert eine Vielzahl unterschiedlicher Messwerte von unterschiedlichen Sensoren verschiedener Fahrzeugkomponenten. Beispielsweise können die Messwerte von folgenden Fahrzeugkomponenten und Subsystemen stammen: diverse interne Messdaten (z.B. zustandsbezogene Messwerte verschiedener Fahrzeugkomponenten), SBM (schadensbezogene Messdaten, z.B. bezüglich Schäden nach Havarie und/oder Kampfeinsatz), EBM (Energiebezogene Messdaten, z.B. Zustandsdaten eines Dieselaggregats), ONA (own noise analysis) und Vibrationsdaten. Insbesondere die Vibrationsdaten sind wichtig um aktuelle und künftige Systemzustände abschätzen zu können, da diese Daten es in den meisten Fällen ermöglichen, mechanischen Betriebsprobleme von sich drehenden Maschinen zu identifizieren, insbesondere Alterungsprozesse in Stahlkonstruktionen.
  • Die Ausgabeschnittstelle 404 kann z.B. ein Bildschirm oder ein Lautsprecher sein oder eine Maschine-zu-Maschine-Schnittstelle. Beispielsweise kann die Schnittstelle eine GUI sein, die dem Nutzer 424 das Ergebnis der Analyse der einzelnen Analysemodule anzeigt, um dem Nutzer zu ermöglichen, geeignete Maßnahmen zu ergreifen.
  • Beispielsweise kann das Analysemodul 410 ein Analyseergebnis erzeugen, wonach die Energievorräte in drei Tagen bei gleichbleibendem Verbrauch erschöpft sein werden. Das Ergebnis wird dem Nutzer über den Bildschirm angezeigt sodass dieser selbst geeignete Maßnahmen ergreifen kann, z.B. rechtzeitig einen Hafen ansteuern oder den Energieverbrauch drosseln. Das Analysemodul für 112 kann durch Analyse mehrerer Messwerte wie zum Beispiel aktuell verfügbare Energievorräte, Strömungsverhältnisse, Windverhältnisse in Kombination mit vom Nutzer spezifizierten Daten wie zum Beispiel gewählter Route für die nächsten Tage die voraussichtliche Reichweite der Energievorräte Vorhersagen. Für den Fall, dass die Berechnung ergibt, dass bei der aktuell gewählten Route die Energievorräte nicht ausreichen, bei Wahl einer alternativ möglichen Route die Vorräte ausreichen würden, kann das Modul die alternative Route vorschlagen, sodass der Nutzer die alternative Route lediglich bestätigen muss um zu bewirken, dass das Automatisierungssystem des Fahrzeugs automatisch das Fahrzeug auf die alternative Route lenkt. Manche Analysemodule können ihr Analyseergebnis auch direkt an einzelne Fahrzeugkomponenten ausgeben. Beispielsweise kann das Modul 410 für den Fall, dass ein Energienotstand auf dem Wasserfahrzeug eingetreten ist, automatisch sämtliche Energieverbraucher auf dem Wasserfahrzeug, die als nicht essenziell für den Betrieb des Wasserfahrzeugs angesehen werden, ausschalten bzw. die Bereitstellung von Energie an diese Energieverbraucher beenden.
  • Zumindest einige der Fahrzeugkomponenten können über eine Schnittstelle 402 verfügen, um erfasste Messdaten auch direkt an eine oder mehrere der Analysemodule 410-422 zu übermitteln. Dies kann insbesondere im Hinblick auf Messdaten sein, die für schnelle Reaktionen einzelner Analysemodule in Echtzeit wichtig sind, da hierdurch Verzögerungen durch das Schreiben der Messdaten in eine Datenbank vermieden werden können, gegebenenfalls können die Messdaten auch im Hintergrund bzw. asynchronen in die Datenbank geschrieben werden.
  • Die hier gezeigten Analysemodule sind nach Anwendungsfeldern gruppiert, zum Beispiel in Module des Energieerzeugungssystems EES, des Wartungssystems, oder des "Service" Systems ). Das Service-System umfasst verschiedene Services, z.B. bezüglich der Erfassung und/oder des Reportings verschiedener Fehler von Komponenten des Wasserfahrzeugs.
  • Nach manchen Ausführungsformen haben verschiedene externe Systeme Zugriff auf die Analysemodule und deren Ergebnisse, zum Beispiel über eine externe Schnittstelle 408. Die Schnittstelle 408 kann zum Beispiel zum Export der Daten der Datenbank 122 im Heimathafen verwendet werden, sodass eine Flottenanalysesoftware die exportierten Daten auswerten kann.
    • Bezugszeichenliste
    • 100
    militärisches Wasserfahrzeug
    102
    Waffensystem
    104
    Antriebssystem
    106
    Navigationssystem
    108
    Rudersystem
    110
    Fahrzeugkomponente
    112
    Drehzahlsensor
    114
    GPS Sensor
    116
    Winkel-/Positions-Sensor
    118
    Drucksensor
    120
    Temperatursensor
    122
    Datenbank
    124
    Automatisierungssystem
    126
    verteiltes Computersystem
    130
    militärisches Wasserfahrzeug
    132
    militärisches Wasserfahrzeug
    134
    Computersystem
    136
    Import-Schnittstelle
    138
    Flottenanalysesoftware
    140
    Bildschirm
    202-208
    Computersystem
    212-230
    Container
    260-268
    Analysemodul-Instanzen
    260, 266
    Instanzen des Analysemoduls AM1
    270-278
    Teile der Daten der Datenbank 122
    240-246
    CPUs
    248-254
    Arbeitsspeicher
    256
    Containerverwaltungssoftware
    280
    Netzwerkverbindung (Intranet)
    282
    CPUs
    284
    Arbeitsspeicher
    286
    Automatisierungssoftware
    288
    Datenbank-Zugriffsdienst
    290
    Computersystem
    292
    Datenverbindung
    302, 304
    Instanzen des Analysemoduls AM2
    306-312
    Instanzen des Analysemoduls AM5
    314-318
    Instanzen des Analysemoduls AM6
    322-332
    öffentliche Verschlüsselungsschlüssel zum sicheren Datenaustausch mit bestimmten Analysemodulen
    334-344
    private Entschlüsselungsschlüssel, spezifisch für bestimmte Analysemodule
    402
    Eingang Schnittstelle
    404
    Ausgabe-Schnittstelle
    406
    Messwerte
    408
    externe Schnittstelle
    410-422
    Analysemodule

Claims (23)

  1. Militärisches Wasserfahrzeug (100), beinhaltend:
    - mehrere Fahrzeugkomponenten (104-110), die jeweils ein oder mehrere Sensoren (112-120) beinhalten, wobei zumindest einige der Fahrzeugkomponenten zu einem Waffensystem (102), einer Antriebseinheit (104) und einem Navigationssystem (106) gehören, wobei die Sensoren zur Erfassung von Messwerten ausgebildet sind, wobei die Messwerte Betriebszustände der Fahrzeugkomponente, die den die Messwerte erfassenden Sensor beinhaltet, und/oder Zustände des Wasserfahrzeugs oder seiner Umgebung angeben;
    - eine Datenbank (122), wobei in der Datenbank eine Historie von Messwerten der Sensoren in Verbindung mit einem Zeitstempel persistent und geschützt gespeichert sind; und
    - ein elektronisches Automatisierungssystem (124), wobei das Automatisierungssystem ausgebildet ist zur automatischen und/oder semiautomatischen Steuerung von zumindest einer der Fahrzeugkomponenten in Echtzeit in Abhängigkeit von den Messwerten und/oder in Abhängigkeit von einer Nutzereingabe eines Nutzers, die in Antwort auf eine Ausgabe der Messwerte über eine Benutzerschnittstelle erfolgt.
    - ein oder mehrere Analysemodule (260-268), die jeweils dazu ausgebildet sind, eine Analyse von zumindest einem Teil der in der Datenbank (122) gespeicherten Messwerte auszuführen,
    - wobei ein Analysemodul eine Software ist, die dazu ausgebildet ist, mittels einem oder mehrerer unterschiedlicher rechnerischer Verfahren Messdaten von einem oder mehreren Sensoren so zu verarbeiten, dass eine Antwort auf eine analytische Fragestellung erzeugt wird, wobei das rechnerische Verfahren ein Verfahren ist, welches im Zuge eines Trainingsprozesses erstelltes mathematische Modells eines Machine-Learning-Programms ist.
  2. Das militärische Wasserfahrzeug nach Anspruch 1, wobei das Wasserfahrzeug umfasst:
    - mehrere zu einem Rechnerverbund (126) miteinander vernetze Computer (202-208), die im Verbund als Host so zusammenarbeiten, dass zumindest eine Instanz der Datenbank bereitgestellt wird; und
    - eine Containerverwaltungssoftware, wobei die Containerverwaltungssoftware konfiguriert ist zur automatisierten Bereitstellung, Skalierung und Verwaltung mehrerer Container (212-230) auf den mehreren Computern auf eine Weise, dass die Computer jeweils als Hostsystem für ein oder mehrere Container dienen, wobei die Container voneinander isoliert sind.
  3. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche, ferner umfassend:
    - wobei das Automatisierungssystem (124) einerseits und die ein oder mehreren Analysemodule (260-268) andererseits voneinander operativ entkoppelt sind; und/oder
    - wobei sowohl das Automatisierungssystem als auch die ein oder mehreren Analysemodule dazu ausgebildet sind, ihre jeweiligen Steuerungs- oder Analyse-Funktionen ohne Nutzung einer Internetverbindung auszuführen.
  4. Das militärische Wasserfahrzeug nach Anspruch 3, wobei die operative Entkopplung realisiert ist durch:
    - asynchrone Arbeitsweise von Automatisierungssystem einerseits und den ein oder mehreren Analysemodulen (260-268) andererseits; und/oder
    - asynchroner Schreib- oder Lesezugriff auf die Datenbank (122) durch das Automatisierungssystem oder durch einen operativ mit dem Automatisierungssystem verbundenen Dienst (288) einerseits und durch die ein oder mehreren Analysemodule (260-268) andererseits; und/oder
    - Instanziierung des Automatisierungssystems einerseits und der ein oder mehreren Analysemodule (260-268) andererseits auf unterschiedlichen Computern (202-208; 290).
  5. Das militärische Wasserfahrzeug nach einem der vorstehenden Ansprüche, wobei de mehreren Analysemodule in mehreren unterschiedlichen Containern (212-230) und damit isoliert voneinander ausgeführt werden.
  6. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 5, wobei in jedem der Container (212-230) maximal eine Instanz von maximal einem Analysemodul (260-268) ausgeführt wird.
  7. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 6, wobei die Containerverwaltungssoftware (256) dazu konfiguriert ist, die Erzeugung von Containern (212-230) und die Instanziierung und das Beenden von Analysemodulen (260-268) so zu orchestrieren, dass:
    - bei Ausfall oder Unerreichbarkeit eines der Computer (202-208) automatisch auf einem anderen der Computer die Container und die Analysemodule gestartet werden, die durch den Ausfall oder die Unerreichbarkeit des einen Computers nicht mehr vorhanden oder erreichbar sind; und/oder
    - bei Überschreiten einer maximalen Zahl der aktuell auf den Computern laufenden Instanzen eines der Analysemodule automatisch eine dieser Instanzen zu beenden und/oder einen der Container, der eine Instanz dieses Analysemoduls beinhaltet, zu löschen; und/oder
    - bei Überschreiten einer vordefinierten maximalen Rechenlast eines der Computer automatisch zumindest einen auf diesem Computer gehosteten Container samt der darin laufende Analysemodulinstanz auf einen anderen der Computer zu migrieren; und/oder
    - bei Unterschreiten einer vordefinierten minimalen Rechenlast eines der Computer automatisch zumindest einen auf einem anderen der Computer gehosteten Container samt der darin laufende Analysemodulinstanz auf diesen Computer zu migrieren; und/oder
    - bei Überschreiten einer vordefinierten maximalen Rechenlast eines der Computer automatisch zumindest einen auf diesem Computer gehosteten Container samt der darin laufende Analysemodulinstanz zu identifizieren, eine Kopie dieses identifizierten Containers samt darin laufenden Analysemodul auf mindestens einem weiteren der Computer zu instanziieren; und Analysen unter Einbeziehung zumindest der Analysemodulinstanz in dem identifizierten Container und der weiteren instanziierten Analysemodulinstanz parallel auszuführen; und/oder
    - bei Unterschreiten einer vordefinierten minimalen Rechenlast eines der Computer automatisch zumindest einen auf einem anderen Computer gehosteten Container samt der darin laufende Analysemodulinstanz zu identifizieren eine Kopie dieses identifizierten Containers samt darin laufenden Analysemodul auf diesen einen Computer zu instanziieren; und Analysen unter Einbeziehung zumindest der Analysemodulinstanz in dem identifizierten Container und der weiteren instanziierten Analysemodulinstanz parallel auszuführen.
  8. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche, wobei zumindest einigen der Analysemodule jeweils ein Teil der Daten der Datenbank spezifisch zugewiesen ist, wobei die Teile der Daten auf eine Weise geschützt gespeichert sind, dass nur dasjenige Analysemodul auf diese lesend und/oder schreibend zugreifen kann, welches diesem Teil der Daten zugewiesen ist.
  9. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche, wobei mehrere (260, 262, 264; 306, 314) der Analysemodule (260-268) jeweils einer (108; 110) der Fahrzeugkomponenten spezifisch zugewiesen sind und dazu konfiguriert sind, zumindest die Messwerte, die von den ein oder mehreren Sensoren dieser einen Fahrzeugkomponente, der sie zugewiesen sind, erfasst werden, direkt oder indirekt über die Datenbank zu empfangen, zu analysieren und das Ergebnis der Analyse auszugeben.
  10. Das militärische Wasserfahrzeug nach Anspruch 9, wobei zumindest eines der mehreren Analysemodule, die einer der Fahrzeugkomponenten zugewiesen ist, dazu ausgebildet ist, eine Analyse durchzuführen, welche beinhaltet:
    - eine Erkennung aktueller oder künftiger kritischer Zustände der einen Fahrzeugkomponente; und/oder
    - eine Vorhersage der Zeit des Eintretens eines kritischen Zustands der einen Fahrzeugkomponente; und/oder
    - dem automatischen Identifizieren von ein oder mehreren Umgebungs-Parametern und/oder Fahrzeugkomponenten-Parametern, die ursächlich für einen kritischen Zustand der einen Fahrzeugkomponente sind; und/oder
    - eine Berechnung einer Handlungsempfehlung an einen Menschen in Bezug auf die eine Fahrzeugkomponente; und/oder
    - eine Berechnung eines Steuerbefehls an die eine Fahrzeugkomponente zur automatischen Durchführung des Steuerbefehls.
  11. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche,
    - wobei die Sensoren von zumindest einer der Fahrzeugkomponenten zumindest einen kryptographischen Verschlüsselungsschlüssel (324, 322, 330, 328, 326, 332) beinhalten,
    - wobei eines der Analysemodule der zumindest einen Fahrzeugkomponente zugeordnet ist und einen zu diesem kryptographischen Verschlüsselungsschlüssel korrespondierenden Entschlüsselungsschlüssel (334, 336, 338, 340, 342, 344) beinhaltet;
    - wobei die Sensoren der zumindest einen Fahrzeugkomponente dazu ausgebildet sind, zumindest einige der von ihnen erfassten Messwerte in verschlüsselter Form in der Datenbank zu speichern und/oder direkt an das der zumindest einen Fahrzeugkomponente zugewiesene Analysemodul zu übermitteln;
    - wobei das zumindest eine Analysemodul dazu konfiguriert ist, die zumindest einigen Messwerte mit dem Entschlüsselungsschlüssel zu entschlüsseln und die entschlüsselten Daten zu analysieren.
  12. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche,
    - wobei die Sensoren von zumindest einer der Fahrzeugkomponenten einen Signierschlüssel beinhalten;
    - wobei eines der Analysemodule der zumindest einen Fahrzeugkomponente zugeordnet ist und einen zu diesem Signierschlüssel korrespondierenden Signaturprüfschlüssel beinhaltet;
    - wobei die Sensoren der zumindest einen Fahrzeugkomponente dazu ausgebildet sind, zumindest einige der von ihnen erfassten Messwerte mit dem Signierschlüssel zu signieren und diese in signierter Form in der Datenbank zu speichern und/oder direkt an das der zumindest einen Fahrzeugkomponente zugewiesene Analysemodul zu übermitteln;
    - wobei das zumindest eine Analysemodul dazu konfiguriert ist, die zumindest einigen Messwerte mit dem Signaturprüfschlüssel zu prüfen und die signierten Daten nur dann zu analysieren, wenn die Signaturprüfung ergibt, dass die Signatur valide ist.
  13. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche, wobei ein oder mehrere der Analysemodule jeweils dazu konfiguriert sind, ihr Ergebnis der Analyse an einen Nutzer und/oder an das Analysesystem auszugeben (404) und/oder in der Datenbank zu speichern.
  14. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche, wobei zumindest eines der Analysemodule dazu ausgebildet ist, eine Analyse (z.B. Korrelationsanalyse, NN-basierte Vorhersage, regelbasierte Vorhersage, etc.) auf den Messwerten mehrerer unterschiedlicher Sensoren von mehreren unterschiedlichen Fahrzeugkomponenten durchzuführen, wobei die Analyse beinhaltet:
    - eine Erkennung aktueller oder künftiger kritischer Zustände von einer Fahrzeugkomponente; und/oder
    - eine Vorhersage der Zeit des Eintretens eines kritischen Zustands einer Fahrzeugkomponente; und/oder
    - dem automatischen Identifizieren von ein oder mehreren Umgebungs-Parametern und/oder Fahrzeugkomponenten-Parametern, die ursächlich für einen kritischen Zustand einer der Fahrzeugkomponenten sind; und/oder
    - eine Berechnung einer Handlungsempfehlung an einen Menschen; und/oder
    - eine Berechnung eines Steuerbefehls an eine der Fahrzeugkomponenten zur automatischen Durchführung des Steuerbefehls.
  15. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche,
    - wobei eine der Fahrzeugkomponenten eine Ruderanlage mit einer Steuereinheit, ein oder mehreren steuerbordseitigen und ein oder mehreren backbordseitigen Rudern beinhaltet, wobei die Steuereinheit dazu ausgebildet ist, die Lage und Bewegung der steuerbordseitigen und backbordseitigen Ruder durch senden von Steuerbefehlen an die steuerbordseitigen Ruder einerseits und an die backbordseitigen Ruder andererseits zu koordinieren, insbesondere zu synchronisieren,
    - wobei die Ruderanlage mehrere Sensoren beinhaltet, die zur Erfassung von Ruderanlage-Parameterwerten ausgebildet sind, wobei die Ruderanlage-Parameter zwei oder mehr der folgenden Messparameterwerte umfassen: aktuelle Lage der Ruder, Schwingungen der Ruder, Bewuchs der Ruder, Schwingungen von Komponenten der Ruderanlage, Schaltungszustände der Ruderanlage;
    - wobei ein oder mehrere der Fahrzeugkomponenten mehrere Sensoren beinhalten, die zur Erfassung von Umgebungs-Parameterwerten ausgebildet sind, wobei die Umgebungs-Parameter zwei oder mehr der folgenden Messparameterwerte umfassen: Wassertiefe, Seegang, Schiffsgeschwindigkeit;
    - wobei eines der Analysemodule ein Analysemodul für die verbesserte Steuerung der Ruderanlage ist und dazu ausgebildet ist, die Ruderanlage-Parameterwerte, die Umgebungs-Parameterwerte sowie Zeitdauern zwischen n einem Senden der Steuerbefehle von der Steuereinheit an die jeweiligen Ruder bis zur Umsetzung der Steuerbefehle zu analysieren, um Korrelationen zwischen den Zeitdauern, den Ruderanlage-Parameterwerten, und den Umgebungs-Parameterwerten zu erkennen und/oder um die Koordination der Ruder der Ruderanlage zu verbessern.
  16. Das militärische Wasserfahrzeug nach einem der vorigen,
    - wobei eine der Fahrzeugkomponenten zumindest einen Sensor zur Erfassung von Schwingungen, insbesondere Vibrationen, dieser einen Fahrzeugkomponente beinhaltet, wobei die eine Fahrzeugkomponente insbesondere eine Radaranlage und/oder die Antriebseinheit ist,
    - wobei eines der Analysemodule dazu ausgebildet ist, die Schwingungen der einen Fahrzeugkomponente zu analysieren, um den aktuellen und oder künftigen Zustand einer anderen der Fahrzeugkomponenten zu berechnen, wobei die andere Fahrzeugkomponente insbesondere eine Ruderanlage ist; und/oder
    - wobei eines der Analysemodule dazu ausgebildet ist, die Schwingungen der einen Fahrzeugkomponente zu analysieren, um eine Steuerung der anderen der Fahrzeugkomponenten zu verbessern, wobei die andere Fahrzeugkomponente insbesondere eine Ruderanlage ist.
  17. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche, wobei einer der Sensoren die Temperatur des das Wasserfahrzeug umgebenen Wassers misst und in der Datenbank speichert, wobei eines der Analysemodule dazu konfiguriert ist, den aktuellen oder künftigen Energieverbrauch und/oder den aktuellen oder künftigen Verschleißgrad einer Fahrzeugkomponente in Abhängigkeit von der Temperatur des als Kühlwasser verwendeten Umgebungswassers zu berechnen.
  18. Das militärische Wasserfahrzeug nach Anspruch 17, wobei das eine Analysemodul dazu konfiguriert ist, die zu verschiedenen Zeitpunkten gemessene Temperatur dazu zu verwenden, gleichartige Betriebsmodi des gesamten Wasserfahrzeugs zu identifizieren, die durch eine bestimmte Temperatur oder einen bestimmten Temperaturbereich des Umgebungswassers definiert sind, wobei das Analysemodul dazu konfiguriert ist, Messdaten und/oder sonstige Leistungsparameter des ganzen Wasserfahrzeugs so zu analysieren, dass nur vergleichbare Betriebsmodi des Fahrzeugs miteinander verglichen werden, und insbesondere um die Vergleichsergebnisse zu verwenden um den künftigen Energieverbrauch, die aktuell maximal mögliche Reichweite und/oder den aktuellen oder künftigen Verschleißgrad des Wasserfahrzeugs oder von Wasserfahrzeugkomponenten zu berechnen.
  19. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche, wobei Daten der Datenbank in den mehreren Computern verteilt und/oder redundant gespeichert sind.
  20. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 19, wobei die Daten der Datenbank verteilt in verschiedenen Containern verschiedener Rechner gespeichert sind, wobei die Containerverwaltungssoftware dazu konfiguriert ist, die Erzeugung von Containern und die Speicherung, Replikation und Löschung der Daten in den Containern so zu orchestrieren, dass:
    - im Normalbetrieb die Daten der Datenbank in redundanter Weise so in den mehreren Computern verteilt gespeichert werden, sodass diese bei Ausfall von einem oder mehreren der Computer aus den in den übrigen Computern gespeicherten Daten rekonstruierbar sind; und/oder
    - bei Ausfall eines der Computer automatisch ein anderer der Computer, auf welchem eine Kopie derjenigen Teile der Daten, die in dem ausgefallenen Computer gespeichert waren, identifiziert wird, und die auf diesem anderen Computer enthaltenen Daten den Analysemodulen und der Automatisierungssystem bereitgestellt werden; und/oder
    - bei Ausfall eines der Computer automatisch Neuverteilung zumindest eines Teils der in mehreren Containern redundant und verteilt gespeicherten Daten derart, dass der bisherige Grad der Redundanz der Daten der Datenbank wiederhergestellt wird; und/oder
    - bei Überschreiten eines vordefinierten maximalen Speicherbedarfs in einem der Computer automatisch zumindest Teile der auf diesem Computer gespeicherten Daten der Datenbank auf einen anderen der Computer zu migrieren oder zu kopieren; und/oder
    - bei Unterschreiten einer vordefinierten minimalen Rechenlast eines der Computer automatisch zumindest einen der auf diesem einen Computer gehosteten Container zu löschen.
  21. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 20, wobei zumindest einige der Rechner des Rechnernetzwerks jeweils in einem eigenen Sicherheitsbehälter enthalten sind, der feuerfest und/oder druckwellenrobust und/oder wasserdicht ist.
  22. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 21, wobei die Rechner des Rechnernetzwerks ein oder mehrere erste Rechner und ein oder mehrere zweite Rechner umfassen, wobei die ersten Rechner und die zweiten Rechner in unterschiedlichen räumlichen Bereichen des Wasserfahrzeugs untergebracht sind, wobei die unterschiedlichen räumlichen Bereiche unterschiedliche Zimmer, unterschiedliche Decks, unterschiedliche durch wasserdichte Schleusentore getrennte Kammern, Steuerbordseite und Backbordseite des Wasserfahrzeugs oder Bugseite und Heckseite des Wasserfahrzeuges sind.
  23. System (150) umfassend:
    - mindestens zwei militärische Wasserfahrzeuge (100, 130, 132) gemäß einem der vorigen Ansprüche;
    - ein Computersystem (134) mit:
    ∘ einer Schnittstelle (136) zum sicheren Import des Inhalts der Datenbanken der mindestens zwei Wasserfahrzeuge;
    ∘ eine Flottenanalysesoftware (138), wobei die Flottenanalysesoftware dazu ausgebildet ist, die Messwerte der Datenbanken der mindestens zwei Wasserfahrzeugen zu analysieren, wobei die Flottenanalysesoftware dazu konfiguriert ist, automatisch zu erkennen, ob die Messwerte unterschiedlicher Wasserfahrzuge von Fahrzeugkomponenten gleichen Typs erfasst wurden, wobei die Analyse umfasst:
    ▪ eine Erkennung desjenigen der Wasserfahrzeuge, dessen Gesamtheit an Fahrzeugkomponenten im besten oder schlechtesten Zustand ist im Hinblick auf zumindest ein technisches Bewertungskriterium; und/oder
    ▪ eine Erkennung kritischer Zustände von einer Fahrzeugkomponente in einem oder mehreren der Wasserfahrzeuge; und/oder
    ▪ eine Vorhersage der Zeit des Eintretens eines kritischen Zustands einer Fahrzeugkomponente in einem oder mehreren der Wasserfahrzeuge; und/oder
    ▪ dem automatischen Identifizieren von ein oder mehreren Umgebungs-Parametern und/oder Fahrzeugkomponenten-Parametern, die ursächlich für einen kritischen Zustand einer der Fahrzeugkomponenten in einem oder mehreren der Wasserfahrzeuge sind.
EP25214488.6A 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren Pending EP4685044A3 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102020200471.4A DE102020200471B4 (de) 2020-01-16 2020-01-16 Militärisches Wasserfahrzeug mit Sensoren
EP21700516.4A EP4090586B1 (de) 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren
PCT/EP2021/050330 WO2021144206A1 (de) 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
EP21700516.4A Division-Into EP4090586B1 (de) 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren
EP21700516.4A Division EP4090586B1 (de) 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren

Publications (2)

Publication Number Publication Date
EP4685044A2 true EP4685044A2 (de) 2026-01-28
EP4685044A3 EP4685044A3 (de) 2026-03-11

Family

ID=74186672

Family Applications (2)

Application Number Title Priority Date Filing Date
EP21700516.4A Active EP4090586B1 (de) 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren
EP25214488.6A Pending EP4685044A3 (de) 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP21700516.4A Active EP4090586B1 (de) 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren

Country Status (6)

Country Link
EP (2) EP4090586B1 (de)
KR (1) KR102784855B1 (de)
BR (1) BR112022014068A2 (de)
DE (1) DE102020200471B4 (de)
ES (1) ES3064700T3 (de)
WO (1) WO2021144206A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021211574A1 (de) 2021-10-13 2023-04-13 Atlas Elektronik Gmbh System zur Authentifizierung einer Kooperation zwischen einer Wechseleinheit und einem Wasserfahrzeug
JP2023141032A (ja) 2022-03-23 2023-10-05 ヤマハ発動機株式会社 船舶推進機情報の送受信システムおよび船舶推進機情報の送受信方法
EP4283506A1 (de) * 2022-05-26 2023-11-29 BAE SYSTEMS plc Steuerung einer komponente eines wasserfahrzeuges
GB2619056A (en) * 2022-05-26 2023-11-29 Bae Systems Plc Controlling a component of an aquatic vessel
US12406346B2 (en) 2022-06-16 2025-09-02 Toyota Motor Engineering & Manufacturing North America, Inc. Vehicle assessment systems and methods
DE102022209654A1 (de) 2022-09-14 2024-03-14 Thyssenkrupp Ag Signaturmanagement unter Berücksichtigung von Satelliten
DE102022209652B4 (de) 2022-09-14 2024-11-21 Thyssenkrupp Ag Signaturmanagementsystem
DE102023127964A1 (de) * 2023-10-12 2025-04-17 Marian Paul Verfahren zur instandhaltung technischer einrichtungen, instandhaltungsverwaltungsvorrichtung, datenerfassungseinheit und instandhaltungsverwaltungssystem
KR102926403B1 (ko) * 2023-10-26 2026-02-12 한화오션 주식회사 잠수함 내 이상 유무를 감지하는 시스템 및 방법
DE102023211581A1 (de) * 2023-11-21 2025-05-22 Zf Friedrichshafen Ag Überprüfung von Sensordaten eines Fahrerassistenzsystems
DE102024115633A1 (de) 2024-06-05 2025-12-11 Thyssenkrupp Ag Verfahren zur akustischen Selbstdiagnose eines Wasserfahrzeugs, insbesondere eines Unterseebootes

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3150895A1 (de) 1981-12-22 1983-07-14 Blohm + Voss Ag, 2000 Hamburg Kampfschiff mit ueber elektronische steuergeraete verbundenen anlagen
US20060058929A1 (en) 2004-02-16 2006-03-16 Marine Cybernetics As Method and system for testing a control system of a marine vessel
US20080120620A1 (en) 2006-09-27 2008-05-22 Richard Lett Systems and methods for scheduling, processing, and monitoring tasks
DE102008025803A1 (de) 2008-05-29 2009-12-10 Man Diesel Se Schiffsbrennkraftmaschine
DE102011086355A1 (de) 2011-08-31 2013-02-28 André Busche Waffensystem und Verfahren zur Verteidigung ziviler Einrichtungen, insbesondere Handelsschiffen
US20180304969A1 (en) 2015-11-26 2018-10-25 Wärtsilä Finland Oy Marine vessel performance diagnostics
US20180356826A1 (en) 2015-06-04 2018-12-13 Bae Systems Plc Decision making
US20190176945A1 (en) 2017-12-07 2019-06-13 Her Majesty The Queen In Right Of Canada Acoustic Response Control System

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CH699530B1 (de) * 2005-03-07 2010-03-31 Klaus Kuhlgatz Anlage und Verfahren für das gesamtheitliche Bewirtschaften von Schiffen.
KR100713168B1 (ko) * 2005-10-11 2007-05-02 한국해양연구원 무인해상경비선의 원격통제장치 및 통제방법
GB2441802A (en) * 2006-09-13 2008-03-19 Marine & Remote Sensing Soluti Safety system for a vehicle
DE102008057123B4 (de) * 2008-11-13 2016-03-31 Peter Friedrich Großkaliber- Artillerie auf kompakten Kampfschiffen und Schnellbooten
US10042697B2 (en) * 2015-05-28 2018-08-07 Oracle International Corporation Automatic anomaly detection and resolution system
WO2017035536A1 (en) * 2015-08-27 2017-03-02 FogHorn Systems, Inc. Edge intelligence platform, and internet of things sensor streams system
KR101701278B1 (ko) * 2015-09-11 2017-02-13 대우조선해양 주식회사 선박/해양플랜트의 원격 검사 및 유지보수 시스템
KR20170043213A (ko) * 2015-10-13 2017-04-21 동명대학교산학협력단 디지털 포렌식 기반의 항해자료 저장장치 및 이를 이용한 방법
EP3810498B1 (de) * 2018-06-21 2022-08-10 Propulsion Analytics I.K.E. - P.C. Fernbeurteilung des bewuchses eines schiffspropellers

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3150895A1 (de) 1981-12-22 1983-07-14 Blohm + Voss Ag, 2000 Hamburg Kampfschiff mit ueber elektronische steuergeraete verbundenen anlagen
US20060058929A1 (en) 2004-02-16 2006-03-16 Marine Cybernetics As Method and system for testing a control system of a marine vessel
US20080120620A1 (en) 2006-09-27 2008-05-22 Richard Lett Systems and methods for scheduling, processing, and monitoring tasks
DE102008025803A1 (de) 2008-05-29 2009-12-10 Man Diesel Se Schiffsbrennkraftmaschine
DE102011086355A1 (de) 2011-08-31 2013-02-28 André Busche Waffensystem und Verfahren zur Verteidigung ziviler Einrichtungen, insbesondere Handelsschiffen
US20180356826A1 (en) 2015-06-04 2018-12-13 Bae Systems Plc Decision making
US20180304969A1 (en) 2015-11-26 2018-10-25 Wärtsilä Finland Oy Marine vessel performance diagnostics
US20190176945A1 (en) 2017-12-07 2019-06-13 Her Majesty The Queen In Right Of Canada Acoustic Response Control System

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANDO, HIDEYUKI: "Smart ship application platform project (SSAP Project", SEA JAPAN 2014, ENVIRONMENTAL TECHNOLOGY SEMINAR, 11 April 2014 (2014-04-11), Retrieved from the Internet <URL:https:/Iwww.mlit.go.jp/common/001039009.pdf>

Also Published As

Publication number Publication date
EP4090586C0 (de) 2025-12-31
EP4090586B1 (de) 2025-12-31
DE102020200471A1 (de) 2021-07-22
EP4685044A3 (de) 2026-03-11
WO2021144206A1 (de) 2021-07-22
DE102020200471B4 (de) 2024-01-04
ES3064700T3 (en) 2026-04-28
KR102784855B1 (ko) 2025-03-20
EP4090586A1 (de) 2022-11-23
KR20220109474A (ko) 2022-08-04
BR112022014068A2 (pt) 2022-09-13

Similar Documents

Publication Publication Date Title
EP4090586B1 (de) Militärisches wasserfahrzeug mit sensoren
US10673635B2 (en) Data management systems and methods
EP3035635B1 (de) System und verfahren zur bewertung von cyber-angriffen auf flugzeuge
US20060235707A1 (en) Decision support method and system
Coyle et al. System dynamics in defence analysis: some case studies
KR20200082390A (ko) 블록체인 기반 선박 사고 데이터 임의 수정을 방지하기 위한 방법
Kim et al. Human Factors in Remote Ship Operations
Jorgensen Autonomous Vessels: ABS’Classification Perspective
Mancini A pragmatic mission-centric approach to ict risk and security-autonomous vehicles as a case
Browne et al. A proposed framework for artificial intelligence safety and technology readiness assessments for national security applications
Diulio et al. Advancements in equipment remote monitoring programs–providing optimal fleet support in a cyber-safe environment
Reith¹ et al. Operationalizing Cyber: Recommendations for Future Research
Bhardwaj Use of Artificial Intelligence for Improving Operational Efficiency in the Armed Forces
Shaveko Maintenance of Autonomous Vessels (advantages and disadvantages) in comparison with Conventional Ships
Calabrese et al. Damage Control System: an application for ship safety and security
LAMPREIA et al. Cybersecurity Risk Assessment: the Ship Maintenance Databases’ Case Study
Bratko et al. The work of government agencies to assess the vulnerability of the state border protection system
Banks et al. Embedded diagnostics enable military ground vehicle
Falidouri Cybersecurity in maritime digital twins
Douglas et al. Platform Intelligence and Control–What Does the Future Look Like?
Neubert Threat-Analysis Oriented Digital Twinning of ML-Powered Future Autonomous Weapon Systems
Liu Robust Strategies and Health Management Practices of Airborne Fire Control Radar
Morcos Improving operational resilience of naval vessels through the modelling of subsystem interdependency
Longo On the cyber security analysis of computerized transportation systems
Vazintari Operational Technology (OT) cyber-risk assessment for maritime vessels

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AC Divisional application: reference to earlier application

Ref document number: 4090586

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: B63G0013000000

Ipc: B63B0079100000

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RIC1 Information provided on ipc code assigned before grant

Ipc: B63B 79/10 20200101AFI20260130BHEP

Ipc: B63B 79/15 20200101ALI20260130BHEP

Ipc: B63B 79/20 20200101ALI20260130BHEP

Ipc: B63B 79/30 20200101ALI20260130BHEP

Ipc: B63B 79/40 20200101ALI20260130BHEP

Ipc: B63G 1/00 20060101ALI20260130BHEP

Ipc: B63G 13/00 20060101ALI20260130BHEP