WO2021144206A1 - Militärisches wasserfahrzeug mit sensoren - Google Patents

Militärisches wasserfahrzeug mit sensoren Download PDF

Info

Publication number
WO2021144206A1
WO2021144206A1 PCT/EP2021/050330 EP2021050330W WO2021144206A1 WO 2021144206 A1 WO2021144206 A1 WO 2021144206A1 EP 2021050330 W EP2021050330 W EP 2021050330W WO 2021144206 A1 WO2021144206 A1 WO 2021144206A1
Authority
WO
WIPO (PCT)
Prior art keywords
analysis
watercraft
computers
database
data
Prior art date
Application number
PCT/EP2021/050330
Other languages
English (en)
French (fr)
Inventor
Bastian Ebeling
Axel Rasch
Original Assignee
Thyssenkrupp Marine Systems 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 Thyssenkrupp Marine Systems Gmbh, Thyssenkrupp Ag filed Critical Thyssenkrupp Marine Systems Gmbh
Priority to BR112022014068A priority Critical patent/BR112022014068A2/pt
Priority to EP21700516.4A priority patent/EP4090586A1/de
Priority to KR1020227024734A priority patent/KR20220109474A/ko
Publication of WO2021144206A1 publication Critical patent/WO2021144206A1/de

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 acquiring measured values.
  • German patent application DE 102008025803 A1 describes a ship's internal combustion engine with a control device for controlling and / or Rege development of the operation of the ship's internal combustion engine.
  • the control device determines target operating parameters for the ship's internal combustion engine based on the position of the ship.
  • German patent application DE 102011 086355 A1 describes a weapon system for object defense, in particular for use on merchant ships, comprising: at least one barrel weapon, a firing device, a sensor system for recording data, in particular environmental and / or target data, and a Authorization system.
  • the authorization system is set up to enable or disable the firing device depending on the receipt of a release signal.
  • German patent application DE 31 50 895 A1 describes a combat ship with systems connected via electronic control devices.
  • electronic control devices are provided which form control signals for the assigned controlled systems from raw information coming from the assigned controlling system.
  • the electronic control devices For each assigned controlled system, the electronic control devices have a correction stage for modifying the control signals formed as a function of a bedding error in the relevant controlled system and / or the controlling system acting on the control device.
  • the US patent application US2018 / 0304969A1 describes a ship with a propeller mounted on a rotatable shaft and a method for converting the Power of a rotating shaft in thrust to drive the ship across the water.
  • the method comprises the acquisition of measured values that are descriptive of the shaft power, an estimate of two excess shaft powers caused by soiling of the propeller and by soiling of the ship's hull, and output of an indication of propeller cleaning and / or hull cleaning depending on the estimated excess Wave power.
  • the US patent application US2019 / 0176945A1 describes a movement control of a ship in a manner that optimally balances performance and noise emissions.
  • the US patent application US 2006/0058929 A1 describes a method for verifying a control system of a ship, in which the control system receives sensor signals from sensors in its operating state and sends control signals to actuators in response to a desired position, speed, course or to keep other things.
  • the US patent application US 2018/0356826 A1 describes a system and method to facilitate decisions on a watercraft.
  • the method includes: acquisition of environmental data of the environment in which the watercraft is located; Generation of a large number of digital models, each of which model an impact of the environment on a corresponding ability 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 has for its object to provide an improved military water vehicle available.
  • the invention relates to a military watercraft.
  • the military watercraft includes several vehicle components, each of which includes one or more sensors. At least some of the vehicle components belong to a weapon system, a drive unit and a navigation system.
  • the sensors are designed to record measured values, where the measured values indicate operating states of the vehicle component that contains the sensor that records the measured values, and / or states of the watercraft or its surroundings.
  • the military watercraft also includes a database.
  • a history of measured values from the sensors in conjunction with a time stamp is stored in the database in a persistent and protected manner.
  • the military watercraft contains an electronic automation system.
  • the automation system is designed for automatic and / or semi-automatic control of at least one of the vehicle components in real time as a function of the measured values and / or as a function of a user input from a user, which in response to a The measured values are output via a user interface.
  • a watercraft designed in this way uses the measurement data recorded by the sensors in two ways: on the one hand, the measurement data are used for this purpose, the automation system directly or indirectly, and thus influencing its control over individual vehicle components. For example, the recorded measured values can be forwarded directly to the automation system as input. Additionally or alternatively, the measured values or at least some of them can be displayed to a user so that the user can decide on the basis of these measured values how the automation system must be operated. The first use of the currently valid measurement data is to influence the control of the watercraft components in real time. On the other hand, the measurement data are also stored in a database.
  • the time course of the generation of the measurement data can be taken from the database, e.g. B. on the basis of the time stamp (preferably UTC or location-independent and unambiguous), each of which indicates the time at which a measured value was recorded.
  • the time stamp preferably UTC or location-independent and unambiguous
  • the content of the database can be used as a training data set in order to train a machine learning algorithm on the basis of this data.
  • hidden, non-obvious or technically indirectly recognizable relationships and interactions can be determined, and in principle in a way that is individual for each vehicle, which is particularly relevant in the military sector with small numbers of items and many custom-made products.
  • the measured values are stored securely in the database, which means that they are protected against unauthorized access by means of security measures, e.g. through encryption or the prevention of anonymous access by granting access rights.
  • Embodiments of the invention thus enable a uniform use and analysis of all accumulating / recordable digital data that arise or can be recorded with the increasingly complex platforms, installations and systems on board a military watercraft, and thereby enable smooth 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 the detailed knowledge of the users of individual vehicle components is often poor or cannot be reliably accessed in military stressful situations. There is a tendency for vehicles and components to become more and more complex and the number of crews ever smaller (down to a crew size of zero, which corresponds to completely autonomous vehicle control).
  • the acquisition and storage of the sensor data in the database can compensate for these disadvantages.
  • the watercraft comprises several (at least two) computers networked with one another to form a computer network, which work together as a host in such a way that at least one instance of the database is provided. It is also possible for some or all of the data in the database to be stored in a redundant manner on the multiple computer systems, for example by generating multiple instances of the database including some or all of the data in the database on the multiple computers.
  • the watercraft comprises container management software that is configured for the automated provision, scaling and management (“orchestration”) of at least one container on at least one of the computers in such a way that this at least one computer serves as the host system for the at least one container, the at least one container isolating programs that run inside this container from programs that run outside of this container.
  • the container management software preferably orchestrates multiple containers on one or more computers.
  • the watercraft comprises several computers networked with one another to form a computer network and container management software.
  • the container management software is configured for the automated provision, scaling and management (“orchestration”) of several (at least two) containers on the several computers in such a way that the computers each serve as a host system for one or more containers, whereby the containers (of the same host Computer system as well as different host computer systems) are isolated from one another.
  • the containers can be orchestrated in such a way that they provide the database or parts of the database and / or one or more analysis modules multiple times, so that a parallel free 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 measured values stored in the database and increases the reliability.
  • the analysis modules provided redundantly according to some embodiments, this also increases the availability (possibly parallel execution of the same type of analysis) and reliability of the corresponding analysis modules.
  • containers for the provision and isolation of software applications ensures the separation and management of the resources used on a computer.
  • the use of containers makes it possible to instantiate an application on different computers and environments (for example different computers in a computer network, but also on computers of different types such as development, QA, production). Updates are also simplified.
  • each of the containers is access-restricted in that it can only access a specific memory area of the main memory that is allocated to it alone, as well as access to native applications (e.g. native databases).
  • native applications e.g. native databases
  • only the analysis modules are hosted within containers, while the database is hosted as a native database on one of the Computer is operated.
  • 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 in such a way that there is a virtual network between some of the containers, so that the analysis modules instantiated in a container access the content of a database that is instantiated within a container networked with its own container, can access.
  • Corresponding embodiments can have the advantage that a user, e.g. via the container management software, can determine very precisely and in a fine-grained manner which analysis modules within which container can access the contents of other containers. For example, it is possible that a first container contains a first database with the measured values from sensors S1, S12 and S37 and a second container contains a second database with the measured values from sensors S17 and S35.
  • the sensors S1, S12 and S37 come from sensors from manufacturer H1, while the measured values from sensors S17 and S35 come from manufacturer H2. It is now possible to configure the computer network or the container so that the analysis software A1 from the manufacturer H1 runs in a third container that is allowed to selectively access the first database in the first container, but not the data from the sensors of the Manufacturer H2 in the second container. Analogously, the configuration can include the fact that the analysis software A2 from the manufacturer H2 runs in a fourth container, which is allowed to selectively access the second database in the second container, but not the data from the sensors from the manufacturer H1 in the first container.
  • the computers can be servers, i.e. computers that transfer one or more programs or functions (e.g. analysis modules, databases, etc.) to external entities (e.g. other servers, analysis modules that are 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 which are each designed to carry out an analysis of at least some of the measured values stored in the database.
  • the automation system, on the one hand, and the one or more analysis modules, on the other hand are operatively decoupled from one another.
  • the one or more analysis modules are designed to carry out their respective analysis function without using an Internet connection.
  • both the automation system and the one or more analysis modules are designed to perform their respective control or analysis functions without using an Internet connection.
  • the analysis modules are designed to analyze the history of the measured values stored in the database and, on the basis of the analysis, make predictions regarding the current and / or future condition of the watercraft or its components and / or a technical or tactical point of view Calculate action.
  • treatment recommendations are first calculated, which are then implemented manually, semi-automatically or fully automatically.
  • At least some of the analysis modules are preferably designed to take the measured values from two or more sensors from two or more different vehicle components and optionally also one or more environmental parameters (air pressure, water temperature, depth, geographical position of the vehicle, flow strength of the surrounding water, etc.) to evaluate.
  • environmental parameters air pressure, water temperature, depth, geographical position of the vehicle, flow strength of the surrounding water, etc.
  • the execution of the control and / or analysis function without using an internet connection can be advantageous since an internet connection is on the high seas is often not reliably available and, even if it is available, is switched off in the military sector in some cases and for some systems in order to increase the security of the system and to reduce the probability of detection.
  • the analysis is carried out on the data in the database and the analysis modules are operationally separate from the automation system. This means that the automation system is not affected by operations for reading and processing the measurement data by the analysis modules. This is advantageous because the automation system is a real-time system that is protected by the operational separation from the reaction speed and / or responsiveness of the automation system being impaired by the execution of the analysis modules. In a military context, it is of great importance that the automation system can react immediately and in real time to current conditions, e.g. to automatically initiate the right steps in combat situations to turn, brake, accelerate and / or defensive or accelerate the watercraft implement aggressive measures.
  • the operative decoupling is implemented by an asynchronous mode of operation of the automation system on the one hand and the one or more analysis modules on the other.
  • the operational decoupling can include the automation system and the analysis modules being programmed in such a way that they work independently of one another, i.e. the automation system does not require data at any point and / or wait for data provided by the analysis module.
  • the operational decoupling can be implemented in the form of asynchronous write or read access to the database by the automation system or by a service operatively connected to the automation system on the one hand and by the one or more analysis modules on the other.
  • the operational decoupling can include the automation system receiving current measurement data from the sensors directly via a first communication channel without the need for prior to or during the data transfer. Transmission via the first channel, the measurement data are written to the database. This means that the automation system receives the current measurement data from the sensors directly and immediately after they have been recorded by the respective sensors and thus without any delay that can occur when the measurement data is written to a data memory. Asynchronously to this, the measurement data are written into the database in order to update the histories of the measurement parameters.
  • the data channel via which this writing process takes place can also be referred to as the second communication channel and, for example, be designed as a multiplicity of database connections that are established by the sensors with regard to the database.
  • the use of the first communication channel and the one or more second communication channels means that even if bottlenecks or delays should occur when writing the measurement data to the database, this does not lead to a delay in the forwarding of the measurement data to the automation system, since the data transmission the measurement data to the automation system is temporally and operationally decoupled from the storage of the measurement data in the database.
  • the watercraft contains a service via which the automation system reads out data from the database and / or writes data generated by the automation system into the database. In this case, the read and / or write access of this service is operationally decoupled from the read / write accesses by the analysis modules.
  • the operative decoupling can be implemented by instantiating the automation system on the one hand and the one or more analysis modules on the other hand on different computers.
  • the asynchronous mode of operation can be implemented in that the automation system is hosted on one or more first computers and the database and the analysis modules on one or more second computers.
  • the automation system on the one hand and the database and the analysis modules on the other can be assigned different CPU and / or working memory resources of a distributed computer network, so that the automation system does not compete with the analysis modules for resources. All of these measures can be advantageous because they ensure that the automation system or the real-time capability of the automation system is not impaired by the storage and analysis of the history of the measurement data.
  • the watercraft comprises several analysis modules, which are carried out in several different containers and thus isolated from one another.
  • there are powerful programs for managing containers on several computers which make it possible, through the redundant creation of several instances of an analysis module within several different containers, to ensure that certain analyzes can be carried out in parallel on different partial data sets of the database data and thus particularly quickly.
  • the generation of several instances of the same analysis module ensures that, even if a computer in the computer network fails or cannot be reached, it is possible to switch immediately to another existing instance of the same analysis module that is running on another computer, and / or that in a short time this other instance can be created in a new container on the other computer.
  • a maximum of one instance of a maximum of one of the analysis modules is executed in each of the containers.
  • the analysis modules can come from different manufacturers of vehicle components.
  • a first analysis module can be provided by the manufacturer of a turbine and designed to analyze measured values with regard to the speed, temperature and vibration behavior of a turbine from the same manufacturer with sensors for speed, temperature and vibration status of the turbine.
  • the analysis can serve various purposes: for example, to determine whether critical system states have been reached that would invalidate the manufacturer's guarantee and / or that require an inspection or overhaul of the turbine.
  • the analysis can also be used to examine how the individual measured values depend on one another, i.e. whether the turbine shows different vibration patterns within different speed ranges, for example.
  • a second analysis module can, for example, be provided by the manufacturer of an engine and can be designed to analyze measured values with regard to the current engine temperature, the current energy consumption of the engine or other engine-related measured values.
  • the analysis can also serve various purposes, such as determining whether a critical engine condition has been reached or exceeded, which can void the manufacturer's guarantee and / or which require an inspection or overhaul of the engine could.
  • the analysis can also be used to examine how the individual measured values depend on one another, i.e. whether the engine shows different vibration patterns and / or performance curves within different temperature ranges, for example.
  • the execution of exactly one instance of an analysis module per container facilitates the orchestration of the container, e.g. 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 one instantiated in this container Analysis module.
  • the container management software is configured to orchestrate the creation of containers, the instantiation and the termination of the analysis modules (within these containers) in such a way that one or more of the following effects occur: - in the event of failure or unavailability of one of the computers, the containers and analysis modules are automatically started on another of the computers, which are no longer available or accessible due to the failure or the inaccessibility of one computer; as a result, the robustness of the analysis functionality of a watercraft can be increased against failure of individual computers; In the military sector in particular, it must be expected that, in combat situations, components of the watercraft, such as individual computers and / or network connections within a computer network, will be destroyed or damaged or at least fail for a short time; the ability of the container management software to generate a new instance of the failed analysis module in such situations is therefore particularly advantageous; and or
  • the "maximum number" can be, for example, a number that was specified manually or automatically in a configuration of the container management software. Maximum means that exceeding this value is viewed as undesirable and induces a certain consequence or action, which is preferably suitable for reducing the number of instances; and or
  • the container management software can therefore perform load balancing functions; and or - If one of the computers falls below a predefined minimum computational load, automatically migrate at least one container hosted on another of the computers, including the analysis module instance running therein, to this computer; the container management software can therefore perform load balancing functions; in some embodiments, that one computer can be disabled or put to sleep to conserve power; and or
  • the container management software can therefore perform upscaling functions; and or
  • the container management software can therefore perform load balancing functions; and or
  • the container management software can therefore perform downscaling functions. This can be advantageous, since the consumption of CPU and main memory resources can be better distributed among the computers of the computer network and a better response time can be achieved. In addition, a needs-based scaling of the containers and the analysis modules instantiated in them can be achieved.
  • a part of the data in the database is specifically assigned to at least some of the analysis modules.
  • the parts of the data are stored in a protected manner so that only the analysis module that is assigned to this part of the data can read and / or write access to them.
  • the assignment can be made in such a way that an analysis module that has been developed by a specific company that has also manufactured a vehicle component or has a contractual relationship with the Fierstellern has access to measurement data that is recorded and stored by sensors of this vehicle component but not the measurement data from the sensors of other vehicle components.
  • the assignment takes place in such a way that an analysis module that was developed by a specific company that has also manufactured several vehicle components or that has a contractual relationship with the Fierstellern these components has access to the measurement data from sensors these several vehicle components were recorded and saved.
  • the analysis module has no access to the measurement data from the sensors of other vehicle components.
  • the assignment takes place in such a way that an analysis module that was developed by a specific company that has also manufactured one or more vehicle components or has a contractual relationship with the operators of these one or more vehicle components has access to the measurement data that have been recorded and stored by the sensors of these one or more vehicle components and also has access to measurement data that has been stored in the database as generally accessible (for each analysis module of the watercraft).
  • the analysis modules of watercraft according to embodiments of the invention can be the measurement data of the database according to any combination of the examples described here.
  • the various forms of specific assignment of measurement data and analysis modules can be advantageous, since the manufacturers of vehicle components can ensure that only analysis modules that the manufacturer trusts have access to the measurement data generated by the sensors for this vehicle component.
  • the installation of sensors of different types on and / or in vehicle components of a military watercraft by the manufacturer of the respective component has the advantage that important status parameters of the vehicle components such as temperature, vibration behavior, load parameters, environmental parameters, etc. are made available .
  • This measurement data is relevant for the manufacturer of the vehicle components, for example for test, development and repair purposes and to determine warranty cases. However, the measurement data are also relevant for the operator of the watercraft (for a better understanding of how the vehicle components work and / or for a better understanding of the interactions between the vehicle components and other components or environmental parameters).
  • a manufacturer of vehicle components therefore has no interest per se in the measurement data relating to this vehicle component being disclosed. This currently prevents the measurement data from the sensors from being integrated into various vehicle components, which is a disadvantage for the operator of military watercraft in terms of safety, because many technically relevant effects, such as a certain behavior of a rudder, a turbine or another complex component of the watercraft, arise only from the complex interaction of several rer vehicle components, each of which can have different internal states.
  • the IT architecture described can be advantageous because on the basis of this IT architecture, the operator of the military watercraft can assure the suppliers or manufacturers of the respective vehicle components (including their sensors) that the measurement data recorded by the sensors are only accessible to certain analysis modules that are viewed and accepted as trustworthy by both sides .
  • An IT architecture will therefore be created that enables the manufacturers of military vehicle components to make sensitive measurement data available in a secure manner only to certain analysis modules. The risk that a competitor or attacker uses the measurement data to replicate or attack a vehicle component can thus be ruled out.
  • the operator of the military watercraft benefits from the fact that the measurement data of a large number of vehicle components according to embodiments of the invention are only provided to selected, trustworthy analysis modules: manufacturers of vehicle components in the military sector have so far tended to collect measurement data from sensors of the vehicle components produced by these manufacturers at best to be recorded internally and only to analyze internal computing units of vehicle components without disclosing the measurement data to the outside world or even storing them over a longer period of time. Thanks to the IT architecture of watercraft according to embodiments of the invention, manufacturers of vehicle components can now dispense with the component-internal computing units for the secret analysis of the measurement data, since the measurement data from several sensors and vehicle components are stored centrally in a database, nevertheless but not every analysis module can access this data at will.
  • Some currently available automation systems for military watercraft also offer access to sensor data from several sensors, but only to the respectively valid actual values of individual systems, which contain historical profiles and trends of the measured values over a longer period of time that are not or only rarely usable. Due to the real-time requirements for such automation systems, it had previously been refrained from burdening the scarce resources of the automation system of watercraft with computationally intensive analyzes of extensive historical databases. Thanks to the distributed provision of the analysis modules in several containers in a computer network detached from the automation system, however, according to embodiments of the invention, it is also possible to carry out complex analyzes, sometimes also in real time, and to provide them without the real-time capability of the automation system being impaired.
  • the analysis modules are each specifically assigned to one of the vehicle components and are configured to directly or indirectly (via the database) at least the measured values that are recorded by the one or more sensors of this one vehicle component to which they are assigned. to receive, analyze and output the result of the analysis.
  • Indirect reception via the database means that the measured values recorded by the sensors are first written to the database and, in a second step, the analysis module then accesses the measured values stored in the database.
  • This indirect reception via the database has the advantage that the analysis modules do not have to have an interface in order to be able to receive measurement data from a specific sensor.
  • the one or more sensors have write rights to the database and are designed to store the measured values in the database in a suitable format.
  • the sensors can have a network interface and be configured in such a way that they continuously write the recorded measured values to the database.
  • the sensors are configured to initially store the measured values recorded by them in a local volatile or non-volatile data memory of the sensor.
  • Another component of the watercraft e.g. the automation system, one of the analysis modules or other software
  • At least one of the plurality of analysis modules that is assigned to one of the vehicle components is designed to carry out an analysis that includes:
  • the one or more analysis modules can be used for this purpose, not just retrospectively individual correlations and combinations. to detect slopes, but based on the history of measurement data from several sensors stored in the database can also be used to predict technically and / or tactically critical situations in or on the watercraft as well as to predict instructions and control commands that can help avoid or mitigate the critical situation.
  • the analysis modules can thus take over functions that were previously only perceived by the automation system.
  • the automation system is typically not very flexible, since it typically integrates measured values from a predefined number of sensors of a predefined set of vehicle components
  • the use of analysis modules in addition to the automation system is advantageous, since the analysis modules according to embodiments of the invention are within an IT architecture are instantiated, which is highly available, robust and easily scalable on the basis of container virtualization and automatic container orchestration and which protects the measurement data of the vehicle components in a secure manner against access by unauthorized third parties.
  • 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, "symmetrical" cryptographic key that is used both for encrypting and decrypting the measured values.
  • the two corresponding keys can be an asymmetric cryptographic key pair, the key managed and stored by the sensor being a public cryptographic key (encryption key) and the securely stored key managed by the analysis module being a private cryptographic key Key (decryption key) is.
  • the sensors of the at least one vehicle component are designed to store at least some of the measured values recorded by them in encrypted form in the database and / or to transmit them directly to the analysis module assigned to the at least one vehicle component.
  • the at least one analysis module is configured to decrypt the at least some measured values with the decryption key and to analyze the decrypted data.
  • all sensors that are 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 is different from the public key of the other sensors of this vehicle component.
  • the sensors of at least one of the vehicle components contain a signature key.
  • the signing key preferably belongs to a PKI of a Fierstellers this vehicle component.
  • One of the analysis modules is assigned to the at least one vehicle component and contains a signature verification key that corresponds to this signature key.
  • the sensors of the at least one vehicle component are designed to sign at least some of the measured values recorded by them with the signature key and to save them in signed form in the database and / or to transmit them directly to the analysis module assigned to the at least one vehicle component.
  • the at least one analysis module is configured to check 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.
  • a specific analysis module can normally be used to predict the future course for the next 5 km based on GPS position data, the current number of rotations of the turbine and a current angle of the rudder.
  • a manipulated angle sensor on the rudder can provide incorrect angle data, which can lead to the course of the watercraft being calculated incorrectly.
  • one or more of the analysis modules are each configured to output their result of the analysis 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 by means of a printer and / or output via loudspeaker. Additionally or alternatively, the results can be output to a software or hardware component, for example to the automation system.
  • the results can integrate the data from a large number of sensors from a large number of vehicle components and / or environmental parameters and can take into account not only current measured values, but also the history of the measured values.
  • the analysis modules are implemented as individual, isolated software modules, the number and composition of the analysis modules can easily change over the life of the vehicle. The changing composition of the vehicle components can be adapted.
  • the analysis results of the analysis modules thus represent a source for system diagnostics and control commands, which supplement the functions of the automation system in a particularly flexible manner.
  • the analysis results can be recommendations for action to be given to a user, the actions having to be carried out by the user or manually.
  • At least one of the analysis modules is designed to carry out an analysis (e.g. correlation analysis, machine learning (ML) -based prediction, rule-based prediction, etc.) on the measured values of several (at least two) different sensors from several different vehicle components .
  • the analysis includes:
  • ML-based methods and various other forms of correlation analysis are particularly suitable for recognizing complex, cross-component, linear and non-linear dependencies and interactions from historical measured values of several different parameters and making predictions on the basis of these recognized dependencies to calculate current and future system states.
  • the data in the database are distributed in the several computers and / or stored redundantly.
  • the data of the database are stored distributed in different containers of different computers (the containers are thus instantiated on different computers, with several containers also being able to be instantiated on some computers).
  • the container management software is configured to orchestrate the creation of containers and the storage, replication and deletion of the data in the containers in such a way that:
  • the data in the database are stored in a redundant manner in the meh eral computers so that they can be reconstructed from the data stored in the other computers in the event of failure of one or more of the computers;
  • At least some of the computers of the computer network are each contained in a separate security container that is fire-proof and / or pressure-wave-robust and / or watertight.
  • the safety container can consist of a single-walled or preferably multi-walled body.
  • the body can be made of steel, for example, and a door can be provided with its own locking mechanism or lock for each body.
  • the safety container is preferably watertight and / or resistant to pressure waves.
  • the body can contain cable feed-through openings on the rear and an integrated cooling system, on the one hand to prevent water and / or pressure from penetrating and on the other hand to prevent overheating.
  • the "containers" are software or runtime environments for programs that are instantiated on a computer
  • the security containers are physical containers that can contain one or more computers.
  • the computers of the computer network include one or more first computers and one or more second computers.
  • the first computer and the second computer are housed in different spatial areas of the watercraft, whereby the different spatial areas have different rooms, different decks, different chambers separated by watertight lock gates, the starboard side and port side of the watercraft or the bow side and stern side of the watercraft are.
  • the invention relates to a system comprising at least two military watercraft according to one of the embodiments or examples described here and a computer system.
  • the computer system contains an interface for the secure import of the content of the databases of at least two watercraft.
  • the computer system also includes fleet analysis software.
  • the fleet analysis software is designed to analyze the measured values in the databases of the at least two watercraft.
  • the fleet analysis software is configured to automatically recognize whether the measured values of different water vehicles were recorded by vehicle components of the same type.
  • the analysis includes:
  • a prediction of the time of the occurrence of a critical condition of a vehicle component in one or more of the watercraft For example, the time at which, in view of the material fatigue that can be derived from the vibration values and / or in view of the usual maintenance intervals, each of the watercraft has the next inspection date, so that the vehicle whose predicted inspection date is furthest in the future than the most suitable for a current, longer one Use can be viewed; and or
  • the fleet analysis software can recognize that only those ships that were sailing in waters with a water temperature of below 6 ° C had problems triggering a movement in a certain component, so that the assumption is that the material contraction occurs at low temperatures Temperatures was the trigger for the problem and the component is not suitable for use at low temperatures.
  • the fleet analysis software can be a single, complex application program or a combination of several individual analysis programs that perform different types of analyzes on the histories of measured values recorded by the sensors of several vessels over a period of several hours, days, weeks, Months or years.
  • the computer system that hosts the fleet analysis software also includes a decryption key and / or signature verification key, these keys being provided by the manufacturer (s) of the vehicle components or the watercraft, if the manufacturer (s) provide these keys for the customer, i.e. the operator of the watercraft.
  • a “military watercraft” is understood here to mean a watercraft that is trained to be used by armed forces to carry out their tasks. Vehicles for military purposes often have specific adaptations, for example reinforced walls or floors to protect against mines, camouflage, weapons and / or defense systems.
  • Watercraft are vehicles that are designed to move on or in the water. In particular, it can be a wind-powered or a machine-powered water vehicle, e.g. sailing ships, air cushion boats, hydrofoils, submarines, frigates, aircraft carriers, supply ships, etc. be trained or equipped on your own ship or the association. Supply ships are trained to support naval action groups, which can be composed of different ships and boats depending on their task.
  • the main logistical task of a supply ship is the supply of operating materials, consumables, provisions and ammunition.
  • a supply ship can also be equipped with a weapon system, e.g. to repel enemy attacks.
  • a “vehicle component” is understood here to be a part of the watercraft which in its entirety fulfills at least one specific function.
  • a vehicle component can be a component, i.e. an individual part of a technical complex, or a system made up of several components that fulfill this function in their entirety.
  • all parts of a certain vehicle component are installed as a unit in a vehicle.
  • a steering system, a radar system, a weapon system, a motor unit, a control unit, etc. can each represent a vehicle component.
  • the electrical signal that can be further processed can in particular comprise data that can be processed by data technology and that represents a representation of the variable.
  • the electrical signal that can be further processed does not necessarily have to be generated in the detector itself, but can also be generated from the output signal of the detector by electronics connected to the detector.
  • a “weapon system” is understood here to be a (often complex) technical defense material, in particular large-scale military equipment.
  • the actual weapon is part of the weapon system.
  • a warship can contain weapons in the form of anti-aircraft missiles in a weapon system designed as a close-range defense system.
  • a weapon system can be a combination of individual technical elements, which interact with each other 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 on a self-propelled gun or a ship deck.
  • the engine power of the watercraft is used both for propelling the watercraft and for aiming the gun, or the weapon system includes its own, independent motor for aiming the gun.
  • An air defense missile system is another example of a weapon system.
  • the various elements such as sensors (e.g. a radar system), control station and launch system of the anti-aircraft missile system can record various measurement data that are processed for monitoring, status control and correct alignment of the radar system and / or the missiles.
  • a “drive unit” here refers to the structural unit that moves a machine, e.g. a ship's turbine, by means of energy conversion. Often this is a motor with a possibly necessary gear.
  • the drive unit can contain a rotary drive or a linear drive.
  • the drive unit can draw its energy from fossil sources (especially oil, natural gas, coal), atomic energy (nuclear fission), battery power and other energy sources.
  • a “navigation system” is understood here to mean a technical system that uses position determination (satellite, radio, GSM or inert or autonomous system) and geographic information (topology, road, air or sea maps) to guide you to a selected destination Place or route, taking into account the desired criteria.
  • a “measured value” is the value of a measured variable that is supplied by a sensor. Examples of measured values are, for example, a temperature in ° C, a position in the form of GPS coordinates, a rotation speed in revolutions per minute, etc. “Measured values” are also referred to as “measured data”.
  • a “database” is understood here as a data structure for the structured storage of data.
  • a database can be a directory tree or a file.
  • a database is preferably a data structure managed by a database management system (DBMS).
  • DBMS database management system
  • a DBMS is a system for electronic data management that is designed to store large amounts of data efficiently, consistently and permanently, and to provide required subsets in different, needs-based forms of representation for users and application programs.
  • a database system offers a database language for querying and managing the data.
  • the database can be a relational database.
  • the structure of the data is determined by a database model.
  • a “history of measured values” is understood here to mean a volume of data which specifies the course over time of several measured values.
  • time stamp is understood here as a data value that specifies a certain point in time, e.g. the point in time (date and time) when a certain measured value was recorded. Time stamps are preferably specified in the coordinated universal time UTC or with reference to this. This can prevent possible misunderstandings due to the globally different time zones.
  • persistently stored is understood here to mean the storage of data on a non-volatile storage medium.
  • protected stored is understood here to mean the storage of data, which technically ensures that only a certain selection of users and / or applications that can identify themselves as authorized to access the protected data can read and / or write to the protected data.
  • protection can consist of storing the data in an access-protected area and / or storing the data in encrypted form so that they can only be read by a program that has a suitable decryption key
  • a “real-time-capable” system for example a real-time-capable automation system, is a system that is designed to carry out a task in "real-time”. That means that the system is able to perform this task continuously within a predefined maximum duration. Typically, this means that the hardware and / or software system mentioned is subject to a "real-time restriction", for example from event to system reaction.
  • Real-time programs have to guarantee the reaction within certain time limits, which are often referred to as "deadlines”.
  • Real-time responses are often understood in the order of milliseconds and sometimes microseconds or seconds.
  • a system that is not specified as real-time operation can usually not guarantee a response within a time frame, although typical or expected response times can be given.
  • a “host” or “host computer” is understood here to mean a computer which alone or in interoperation with one or more other computers provides a certain software program (guest software program), ie makes it available for 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 here to mean a runtime environment for software programs which contains and provides all of the system components required for the execution of these software programs and which isolates the software programs running within this container from programs outside the container.
  • a container can be a virtual machine that is created and managed by a hypervisor (program for managing the virtual machines).
  • a container is preferably a runtime environment that can be managed by means of a container virtualization program.
  • Containers according to these embodiments typically require fewer resources than virtual machines, since they do not have to start their own operating system and instead run in the context of the host operating system. Nevertheless, the containers are sealed off from each other and from the host system, although not as strongly as with virtualization.
  • the free software “Docker” can be used to define containers and isolate applications from one another using container virtualization. Docker simplifies the provision of applications because containers that contain all the necessary packages can be easily transported and installed as files. Docker packs the application and all system components required for its execution in 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 a more flexible application infrastructure that is easier to change, expand and scale.
  • Container virtualization is a method to operate several instances of an operating system (as so-called "guests") isolated from each other on a host system. In contrast to virtualization using a hypervisor on the basis of several virtual machines, container virtualization has some restrictions in terms of the type of guests, but is considered to be particularly resource-efficient.
  • Container virtualization is based on several principles that are implemented differently in individual software products for container virtualization. However, one core of these is always similar: several containers share a kernel and isolate at least some of the operating system resources used from one another.
  • the open source program Kubernetes can be used as a container management program.
  • Kubernetes is container orchestration software that enables applications to be orchestrated easily and efficiently across multiple hosts.
  • Kubernetes enables simplified or even fully automated deployment, operation, maintenance and scaling of container-based applications.
  • Groups of hosts on which the containers run are combined in clusters of physical or virtual machines and managed as a unit.
  • Kubernetes defines a container runtime interface (CRI) that container platforms must implement in order to be orchestrated using Kubernetes. These implementations are also known as “shims”. What makes the Kubernetes platform agnostic: in addition to or instead of Docker, other platforms with appropriate shims, such as B. CRI-0 or KataContainers can be used.
  • Container management software is understood here to mean software that is configured for the automated provision, scaling and management (“orchestration”) of several (at least two) containers on several computers in such a way that the computers each act as a host system for one or more Containers are used, the containers (of the same host computer system as well as different host computer systems) being isolated from one another.
  • complex vehicles can be several hundred containers.
  • Kubernetes can be used as container management software.
  • An “analysis module” is understood here as meaning software that is designed to process measurement data from one or more sensors using one or more different computational methods in such a way that an answer to an analytical question is generated.
  • 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 technical method can be a heuristic, a rule explicitly specified by a programmer, a mathematical and, in particular, statistical algorithm, for example a correlation analysis method, or some other explicitly formulated computation method.
  • the computational method can also be a method which is only formulated implicitly, for example in the form of the mathematical model of a machine learning program created in the course of a training process.
  • the model can be specified in the network architecture and the weights of network nodes in a neural network.
  • the analytical question can concern various questions, e.g. a question about the current or future predicted condition of a vehicle component (parameters for vibration, conductivity, elasticity, etc. indicate critical wear condition?), Or a question about which measurement parameter values coincide a critical condition The system status has been reached or is likely to be reached in the future, the question of 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.
  • An “encryption key” is understood here to be a cryptographic key that is designed to be used to encrypt data.
  • DES Data Encryption Standard
  • AES Advanced Encryption Standard
  • Asymmetrical methods such as the RSA cryptosystem, use key pairs that consist of a public key and a private key.
  • the public key is not secret; it is at least made known to the party who is to send data in encrypted form to the owner of the secret key.
  • the public key can be used to encrypt data.
  • a public key can be clearly assigned to a specific entity, e.g. a user or an analysis module.
  • the private key is required.
  • symmetrical procedures in which several parties share a secret key
  • asymmetrical procedures only one party has the private (secret) key. It is therefore essential that the private key cannot be derived from the public key.
  • An “automation system” is understood here to mean a system for fully automatic or semi-automatic control of a watercraft.
  • the control takes place by means of defined rules based on current measured values from one or more sensors, which are converted into control commands by the automation system, and / or takes place on the basis of control commands that a user enters via a user interface.
  • the automation system is preferably a real-time capable automation system.
  • the automation system is designed to not only have current measured values and / or to receive manually entered control commands as input and to control the vehicle accordingly, but also results of the analyzes from one or more of the analysis modules, the automation system interpreting and implementing the results as control commands.
  • a “computer network” or computer cluster, usually simply called a cluster, is understood here to mean a number of networked computers.
  • the network can be configured in such a way that the computing capacity and / or the availability of the computers or the services provided by them is increased.
  • the computers (also called “nodes”) in a computer network are often referred to as servers.
  • the computers in the network of computers each host one or more containers, the distribution of which on the computers is orchestrated by container management software. Analysis modules or other programs can be run in the containers, which can be implemented as a service, for example, and the results of which can be made available to specific vehicle components. Because of this function of providing analysis results, the computers can also be referred to as “servers”.
  • FIG. 1A shows a block diagram of a military watercraft with several vehicle components equipped with sensors
  • 1B shows a system comprising several military watercraft and a computer with a fleet analysis software
  • Figure 2 is a block diagram of a distributed computer system that can be used to store and analyze sensor measurement data
  • FIG. 3 shows several analysis module-specific asymmetric cryptographic key pairs and their use;
  • Fig. 4 components of a military watercraft with several databases and analysis modules.
  • FIG. 1A illustrates a block diagram of a military watercraft 100 with several vehicle components equipped with sensors.
  • the vehicle components include a propulsion system 104 which includes, for example, a diesel powered marine engine with a transmission coupled to the engine.
  • the drive system contains several sensors for measuring various parameters of the engine and the transmission, including a sensor 112 for the speed of a shaft that is mechanically coupled to the transmission.
  • the vehicle components of the watercraft also 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.
  • 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.
  • an electronic monitoring unit 110 with a plurality of sensors is installed in the vehicle as a further vehicle component which contains a plurality of 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, air humidity, air temperature, water temperature, flow strength of the water and / or other parameters.
  • the automation system is a fully automatic or semi-automatic system for monitoring and controlling internal states of the watercraft and for controlling the movement or other actions of the vehicle or its components.
  • the automation system is a real-time system that is designed to use the measured values received from the sensors and inputs from users via a user interface in order to control the watercraft as a function of these. Over time, a large amount of measurement data accumulates during ongoing operation of the ship, which is provided with a time stamp, which reflects the time at which the measurement data was generated.
  • the measurement data and their time stamp are stored in a database 122 and thus form a history of the parameter values recorded for one or more measurement parameters.
  • the database is, for example, a relational database, e.g. PostgreSQL or MySQL database, or e.g. to 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. However, it is preferably a computer network that comprises several computers that are connected to form a functional unit. Such a computer network is described in more detail, for example, with regard to FIG.
  • the watercraft also includes a weapon system 102 which also includes sensors (not shown). Since the watercraft is also important as a target for opposing forces due to the weapon system and also represents a potential danger for its own crew as well as for uninvolved third parties in the event of a malfunction, safe operation of the automation system is particularly important. "Safe operation” here means that the automation system as well as the data on the basis of which it makes its decisions must be protected from manipulation by third parties.
  • Example 1 Improved supervision and control of a steering gear
  • the watercraft can be an overseas water vehicle with a rudder system, in particular a double rudder system.
  • the steering system has a control system that is designed to monitor the position of the rudder and to control it via an adjustment system.
  • Embodiments of the invention counter this problem as follows: A rudder system is used which contains a large number of sensors for several different rudder system-specific parameters, referred to here as “rudder system parameters”.
  • the steering gear parameters include two or more of the following parameters: pressures of oil circuits in the steering gear, voltages of the electrical control system of the steering gear, currents of the electrical control system of the steering gear, position of the rudders and / or accelerations (especially vibrations) occurring on the rudder shafts.
  • the sensors of the steering gear are configured to regularly measure a steering gear parameter within comparatively short time intervals (e.g.
  • the recording frequency of the sensor can also be dynamically adapted to the circumstances, for example increasing the measurement frequency when one or more relevant parameters change above a predefined limit value.
  • the time stamp can, for example, indicate the point in time when a measured value is stored in the database, where this point in time is very close to the point in time when the measured value was recorded and therefore also at least approximately represents this point in time.
  • Embodiments implicitly record the times that a steering gear needs until the oars implement the given control commands under given environmental conditions and the given condition of the steering gear and have reached the desired positions, because the measurement data and preferably also the control commands are provided with time stamps and in stored in the database.
  • measured values and rudder gear states can be related in a simple manner to the times at which the control system sent control commands to the actuating system.
  • an analysis module which, on the basis of the measured values of steering gear parameters, ambient parameters and steering gear control commands stored in the database and linked with time stamps, determines the times until a control command under the respective prevailing conditions completely differs from the one given by the command affected rowing has been implemented. The times determined are used by the analysis module to adapt the sending of the control commands and / or the content of the control commands so that the synchronization of the rudders of the steering gear is improved.
  • the analysis module is configured, for example, to detect correlations between measured rudder lay times and value ranges of rudder system parameters and environmental parameters.
  • a large number of factors are therefore taken into account, not just a current deviation of the rudder position from the target position, in order to determine whether and when a rudder will assume a desired position.
  • Any asynchronicities between the rudders on the backboard side and on the control board side can thus be detected early and reliably and make it possible to react early and to adapt the control commands to individual rudders quickly and dynamically, according to preferred embodiments in real time.
  • a prediction of asynchronicities also makes it possible to predict necessary maintenance work and simplifies the relevant planning.
  • the analysis module for improved control of the steering gear can, for example, use the acceleration or vibration data to identify possible causes for asynchrony and output them to a user.
  • the acceleration data vibrations
  • the other steering gear parameter values and environmental parameter values are taken into account in the analysis. This can be advantageous because the oscillations and vibrations that occur depend heavily on the water depth, rudder position, swell, vegetation, switching states of the steering gear and the ship's speed. Without taking the context into account, the acceleration data are therefore often insufficient to enable precise control of the steering gear or an exact prediction of the date for the next required maintenance.
  • the vehicle components of the watercraft comprise a steering system with a control unit, one or more starboard-side and one or more port-side oars.
  • the tax income unit is designed to coordinate, in particular to synchronize, the position and movement of the starboard and port rudders by sending control commands to the starboard rudder on the one hand and to the port rudder on the other.
  • the steering gear contains several sensors designed to record steering gear parameter values, the steering gear parameters including two or more of the following measurement parameter values: current position of the oars, vibrations of the oars, fouling of the oars (e.g. by means of an optical sensor or with a force sensor , which measures the force in the direction of the flow), vibrations of components of the steering gear, switching states of the steering gear.
  • One or more of the other vehicle components and / or the steering system also contain several sensors that are designed to detect environmental parameter values, the environmental parameters including 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 the improved control of the steering gear and is designed to analyze the steering gear parameter values, the ambient parameter values and the time between sending the control commands from the control unit to the respective rudder until the control commands are implemented in order to identify correlations between the time periods, the steering gear parameter values, and the environmental parameter values and / or to improve the coordination of the oars of the steering gear.
  • the analysis module for improved control of the rudder system can be designed to automatically determine that, given the sea state and vegetation, the command to the starboard rudder must be sent 400 milliseconds earlier than the corresponding control command to the port rudder.
  • the analysis module sends a corresponding control command to the control unit of the steering gear, thereby causing the control unit to send the command to the starboard rudder only after the said delay to the port rudder.
  • the analysis module for the improved control of the steering gear is designed to measure the steering gear parameter values, the environmental parameter values, the time periods between sending the control commands from the control unit to the respective rudder to the implementation of the control commands and, in addition, status and / or to analyze vibration parameter values that have been recorded by sensors of other vehicle components, in particular the engine and / or the transmission and / or a radar system, in order to establish correlations between the time periods, the steering gear parameter values, the ambient parameter values and to recognize the state and / or vibration parameter values of the other vehicle components and / or to improve the coordination of the rudders of the steering gear.
  • a radar system can be excited by the frequency generated by a drive diesel engine at a certain speed, which leads to a ne negative influence on the steering gear.
  • control can be implemented in the form of logic rules.
  • these rules can also be used to control other watercraft components.
  • one of the logic rules can include that an internal combustion engine can only be started when at least one exhaust gas path is open. This rule is carried out every time this engine is started and, depending on the result of the test as to whether an exhaust path is open, either such an exhaust path is opened automatically or the start process is aborted - possibly accompanied by a message to the user.
  • Example 2 Improved detection and prediction of consumption and conditions
  • Environmental parameters and condition-related parameters of vehicle components depend on one another in a complex manner. For example, when the sea water temperature is higher, the cooling systems that use sea water for cooling work differently than when the sea water is cold. The power consumption increases and the diesel engines used to generate electricity are more heavily loaded. This in turn has an impact on the maintenance and wear of the units, which are not only subjected to higher loads due to a higher seawater temperature because more energy has to be used for cooling, but are also less able to implement their own cooling because the machines and capsules are in are usually cooled with seawater just like the engine itself. The performance characteristics of seawater-cooled vehicle components are therefore often difficult to compare and the predictions regarding their energy consumption are subject to uncertainties.
  • 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.
  • similar operating modes of the entire watercraft can be found automatically, e.g. operating modes that are defined by the temperature of the surrounding water in order to take into account the evaluation of measurement data and / or other performance parameters of the entire watercraft so that only comparable operating modes of the vehicle can be compared with each other.
  • the one analysis module is configured to use the temperature measured at different times to automatically identify similar operating modes of the entire watercraft that are defined by a specific temperature or a specific temperature range of the surrounding 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 vehicle are compared with one another, in particular to determine the future energy consumption, the current maximum times possible range and / or to calculate the current or future degree of wear.
  • both the commissioning and the use phase of various vehicle components can be improved.
  • a detection system and analysis module can be developed as described for example 1 at least for the steering system of the vehicles.
  • the steering systems of the different vehicles can, but do not have to, be of the same type (e.g. come from the same Fiersteller). Because even if the steering systems differ slightly, at least subsystems such as the individual sensors of the steering system or the control unit can be of the same type or comparable. Often times, different brakes for certain vehicle components use the same components provided by a supplier.
  • cross-platform evaluations can be carried out. For example, at least some of the historical data can be imported into the central database in the course of a watercraft's stay in the home port and deleted from the watercraft's database. This increases data security and reduces the storage requirements of the watercraft's database.
  • the different data sets can be useful in several ways.
  • the fleet analysis software can, for example, by analyzing various environmental parameters such as air and water temperature, flow conditions, etc. determine whether the vehicles or vehicle components were operated under comparable conditions or identify those vehicles and components that were operated under comparable, ie sufficiently similar, conditions .
  • the fleet analysis software can then analyze and recognize whether vehicle components of a certain type or manufacturer are better or worse in terms of one or more performance parameters than functionally equivalent vehicle components of a different type or manufacturer. In this way, a problem that has already occurred on one vehicle component can be prevented, if necessary, on another. Furthermore, it can be determined across all vehicles how a certain vehicle component can be operated better or should not be operated in order to avoid certain damage.
  • FIG. 1B shows a system 150 with a plurality of military watercraft 100, 130, 132.
  • Each of the watercraft can be designed as a watercraft of the embodiments described here.
  • the What servehicles all belong to the same or a similar type of vehicle.
  • the watercraft belong to different vehicle types; in this case too, an evaluation of the sensor data histories for several watercraft can be advantageous, e.g. if the vehicles of different types contain some or more vehicle components of the same type, so that a comparison can be made the component-related measured values makes sense at least for these vehicle components.
  • the system 150 also contain a computer system 134, which can be designed, for example, as an individual computer or a group of computers.
  • the computer system contains an interface 136 for the secure import of the content of the databases of the watercraft 100, 130, 132.
  • the interface 136 can be implemented differently. It can be done, for example, via a wired interface, for example based on fiber optic technology, which allows large amounts of data to be transmitted quickly. In some cases, however, it can also be a contactless interface, for example via an interface of a radio link, or a USB interface for importing data on a portable drive via USB. In any case, several technical and / or organizational security precautions are taken to ensure that the data cannot be read out or manipulated during transmission.
  • the transmission can only take place in encrypted form via an end-to-end encrypted data transmission channel.
  • authentication of the user who initiated the data transmission may be required, for example via password-based and / or biometric authentication methods.
  • the computer system 134 and the 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 watercraft during their operations.
  • the evaluation of the data from several watercraft is carried out by fleet analysis software 138, which is instantiated on the computer system 134.
  • the fleet analysis software analyzes the imported measured values from the databases of the watercraft.
  • the imported data can, for example, be stored in a central relational database on the computer system 134 and analyzed there.
  • the fleet analysis software automatically detects whether the measured values of different water vehicles have been recorded by vehicle components of the same type. This information can be helpful in ensuring that the correct readings are being compared.
  • An engine temperature sensor measures the engine temperature
  • a temperature sensor on the outside of the vehicle below the water level measures the water temperature.
  • the speed dial is also included in the analysis.
  • the fleet analysis software uses the imported measurement data to identify which of the watercrafts are optimal or worst in terms of at least one specific target criterion.
  • the target criterion is a technical evaluation criterion such as the vehicle with the best level of energy and spare parts reserves, the vehicle with the lowest maintenance backlog and / or with the longest time until the next inspection is due.
  • the fleet analysis software recognizes critical states of vehicle components in one or more of the watercraft ge. For example, the fleet analysis software can identify all those vehicles in which vibration parameters indicate that temperatures and / or speed values have been measured in an engine within the last 6 months, e.g. due to material fatigue or other unfavorable factors, that are dangerous for the vehicle components and / or the crew must be viewed.
  • the fleet analysis software is designed to predict the point in time of the occurrence of a critical condition of a vehicle component in one or more of the watercraft. That could be the point in time at which energy, oxygen gas or food supplies run out, at which failure of an essential component due to wear and tear is to be expected, or the like.
  • 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 of one of the vehicle components in one or more of the watercraft. This is a particularly advantageous aspect, especially in the context of highly complex military water vehicles: vehicle components and parts are sometimes defective well before the expected normal end of life without a clear cause being identified. Sometimes it can also be observed that a certain component in a certain watercraft fails again and again, while the same component lasts significantly longer in other watercraft of the same type and with the same components.
  • the cause of the problem is an interaction of the component with its environment, although it is not exactly known which cause is specifically responsible for the failure of the component.
  • the mechanical loads on components depend on a wide variety of factors, for example the vibration behavior of spatially adjacent components, the swell, wind and flow conditions to which the vehicle is exposed during its use last but not least also from manually entered control commands of the crew.
  • FIG. 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 includes 5 computers 202, 204, 206, 208, which are functionally connected to a network of computers via a network 280, for example an intranet, and on each of which several containers 212-230 are instantiated.
  • Each of the computers has one or more processors 240, 242, 244, 246, main memory 248, 250, 252, 254 and optionally also one or more non-volatile data memories.
  • Each of the containers contains a maximum of one instance of an analysis module and is executed there.
  • the analysis modules can each be implemented as a so-called microservice.
  • analysis module AM2 runs only in the form of a single instance 262 within the container 214
  • the analysis module AM3 only in the form of a single instance 264 in the container 216
  • the analysis module AM4 only in the form of a single instance 268 in the container 222 but also in several instances within half of a corresponding number of containers are executed.
  • analysis module AM1 is instantiated in the form of the two instances 260, 266 in containers 212 and 220, respectively.
  • the software 256 orchestrates the instantiation, migration and closing of containers and the analysis modules contained therein dynamically according to various optimization criteria, which can preferably be configured by a user. Optimization criteria can, for example, be load balancing, upscaling and downscaling criteria that ensure that the computing load is evenly distributed among the computers, that some frequently required analysis modules can be executed in parallel in several instances, and that a fast response time and / or high reliability is guaranteed .
  • the measurement data recorded by the sensors of the various vehicle components of the watercraft 100 are stored in a database 122.
  • the contents of the database are stored in a redundant manner on the various computers 202-208.
  • Various methods for distributed, redundant storage of data are known in the prior art, for example storage by means of error correction methods using error correction bits.
  • some of the containers 224-230 can also be used to store parts of the data in the database.
  • the automation system 124 also includes one or more processors 282, main memory 284 and automation software 286.
  • the automation software is configured to dynamically receive currently recorded measurement data from at least some of the sensors and, if necessary, together with commands entered by a user, to be used as an input in order to derive one or more control commands from this input and to automatically control the behavior of the one or more vehicle components 102, 104, 106, 108, 110 on the basis of 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 use this data to read from the distributed database 122 and to use it for the calculation of 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.
  • FIG. 3 shows several analysis module-specific asymmetric cryptographic key pairs which can be used for the secure transmission and storage of measurement data.
  • the drive system 104 can be produced by a first manufacturer H1.
  • the manufacturer H1 is also developing an analysis module AM4 that is designed to analyze measured values that are recorded by one or more sensors 112 of the drive in order to automatically predict the current and / or future state of the drive system 104.
  • the manufacturer H1 Before or during the development of the analysis module AM4, the manufacturer H1 generates a first asymmetrical 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 in the analysis module AM4 in such a way that it cannot be read out by unauthorized third parties.
  • the speed sensor 112 of the drive system 104 is provided with the public encryption key 332.
  • the public keys can be created specifically for each individual sensor of a vehicle component together with their corresponding private keys. In other embodiments, however, it is also possible that all sensors of a vehicle components share the same cryptographic key pair or the public key of this pair and use the public key to encrypt the measurement data recorded by the sensors.
  • a sensor-specific generation of key pairs has the advantage of a very fine-grained control of the access rights.
  • a vehicle component-specific generation of key pairs and the use of the same public key by the sensors of the same vehicle component has the advantage of simplified key management, because usually, if not always, the measurement data recorded by different sensors of a vehicle are identical or similar requirements for their confidentiality.
  • the speed sensor 112 is configured to encrypt copies of the measured values recorded by it with a public key 330 that is assigned to an analysis module AM3 of another Fierstellers H2, so that this analysis module AM3 the copies with its corresponding private cryptographic Can decrypt key 342.
  • a public key 330 that is assigned to an analysis module AM3 of another Fierstellers H2
  • this analysis module AM3 the copies with its corresponding private cryptographic Can decrypt key 342.
  • there can be contractual relationships of trust between the lowering actuator FH 1 and the lowering actuator FH2 of the rudder 108 so that the sensor 112 of the drive system encrypts the measured values recorded by it not only with the public key 332, but also as a copy with the public key 330, so that not only analysis module AM4 but also analysis module AM3 can access and decode these measured values.
  • the vehicle component 110 which contains a temperature sensor 120 and a pressure sensor 118, can be manufactured by a third Fierstelle FH3.
  • the Fiersteller FH3 also develops the analysis modules AM5 and AM6, which can be instantiated in several copies on the computer system 126. nen. Modules AM5 and AM6 each evaluate both temperature data and pressure data, but with regard to different analysis purposes or questions.
  • the sensor 120 generates its measurement data in the form of two copies of measurement data that are encrypted with different public keys 324, 322.
  • the sensor 118 also generates its measurement data in the form of two copies of measurement data that are encrypted with the public keys 324, 322.
  • Data that have been encrypted with the key 322 can be decrypted and processed by any analysis module that contains the associated private key 334.
  • Data that have been encrypted with the key 324 can be decrypted and processed by any analysis module that contains the associated private key 336.
  • Each of the multiple instances 306-312 of the analysis module AM5 contains the private key 334.
  • Each of the multiple instances 314-318 of the analysis module AM6 contains the private key 336.
  • the rudder 108 includes three sensors of different types, including the angle sensor 114.
  • Each of the sensors is assigned a public key 326-330, which forms an asymmetrical cryptographic key pair with a corresponding private key 338-342.
  • the measured values recorded by the sensors are encrypted in triplicate and stored in the database with a different public key.
  • Analysis module AM1 can only decrypt data that has been encrypted with the public key 326.
  • Analysis module AM2 can only decrypt those data that were encrypted with the public key 328.
  • the analysis module AM3 has two private keys 340, 342 and can therefore decrypt data that has been encrypted with the public key 328 or with the public key 330.
  • a single particularly trustworthy software has a copy of all the private keys of the analysis modules.
  • the particularly trustworthy software can be a further analysis module with extended authorization that was developed by the operator of the vehicle.
  • the fleet analysis software can have a copy of all private keys of the analysis modules in order to be able to analyze the data from all sensors of all watercraft in a fleet.
  • FIG. 3 shows the assignment of private decryption keys to the individual analysis modules and the assignment of public encryption keys to the sensors (or vehicle components containing these sensors).
  • the sensors collect measurement data and encrypt them with the public keys assigned to them.
  • asymmetrical cryptographic key pairs are assigned to the sensors and analysis modules, but for the purpose of signature verification (not shown here).
  • the private signing key is assigned to the individual sensors or to the vehicle components containing these sensors.
  • the sensors or vehicle components use the signing key to transfer the recorded and optionally encrypted rarely to sign measurement data.
  • the individual analysis modules have access to public signature verification keys, which each form an asymmetrical 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 signatures of the measurement data with signature verification keys and to process the measurement data only if their signature is valid.
  • FIG. 4 shows, by way of example, some components of a military watercraft with several analysis modules (“AMs”) and a database 122.
  • the database 122 is implemented here in the form of two different databases, each of which contains different parts of the data.
  • Database 122.1 contains measurement data with a normal security level, which are available in whole or in part in unencrypted form.
  • Database 122.2 contains sensitive measurement data, which are also referred to as "red data" in the military sector, and which are preferably encrypted with one or more different cryptographic keys, e.g. according to an encryption method described with reference to FIG.
  • the box 406 represents a large number of different measured values from different sensors of various vehicle components.
  • the measured values can come from the following vehicle components and sub-systems: various internal measured data (e.g. condition-related measured values of various vehicle components), SBM (damage-related measured data, e.g. regarding damage after flavarias and / or combat operations), EBM (energy-related measured data, e.g. status data of a diesel unit) , ONA (own noise analysis) and vibration data.
  • various internal measured data e.g. condition-related measured values of various vehicle components
  • SBM damage-related measured data, e.g. regarding damage after flavarias and / or combat operations
  • EBM energy-related measured data, e.g. status data of a diesel unit
  • ONA own noise analysis
  • vibration data in particular are important in order to be able to estimate current and future system states, since these data make it possible in most cases to identify mechanical operating problems of rotating machines, in particular aging processes in steel structures.
  • the output interface 404 can be, for example, a screen or a loudspeaker or a machine-to-machine interface.
  • the interface can be a GUI that provides the user 424 with the result of the analysis of the individual analyzes. semodule to enable the user to take appropriate measures.
  • the analysis module 410 can generate an analysis result, according to which the energy supplies will be exhausted in three days with constant consumption. The result is displayed to the user on the screen so that they can take appropriate measures themselves, e.g. head for a port in good time or reduce energy consumption.
  • the analysis module for 112 can predict the probable range of the energy supplies for the next few days by analyzing several measured values such as currently available energy supplies, flow conditions, wind conditions in combination with data specified by the user, such as the route selected for the next few days.
  • the module can suggest the alternative route so that the user only confirms the alternative route has to cause the vehicle's automation system to automatically steer the vehicle onto the alternative route.
  • Some analysis modules can also output their analysis results directly to individual vehicle components. For example, in the event that an energy emergency has occurred on the watercraft, the module 410 can automatically switch off all energy consumers on the watercraft that are not considered to be essential for the operation of the watercraft or terminate the provision of energy to these energy consumers.
  • At least some of the vehicle components can have an interface 402 in order to also transmit recorded measurement data directly to one or more of the analysis modules 410-422.
  • This can be particularly with regard to measurement data, which are important for fast reactions of individual analysis modules in real time, since this avoids delays caused by writing the measurement data in a database; if necessary, the measurement data can also be written in the background or asynchronously in the database become.
  • the analysis modules shown here are grouped according to application fields, for example in modules of the energy generation system EES, the maintenance system, or the "service" system).
  • the service system comprises various services, for example with regard to 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 the database 122 in the home port, so that a fleet analysis software can evaluate the exported data can.

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)

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

Militärisches Wasserfahrzeug mit Sensoren
B e s c h r e i b u n g
Gebiet
Die Erfindung betrifft ein militärisches Wasserfahrzeug, insbesondere ein militäri sches Wasserfahrzeug mit Sensoren zur Erfassung von Messwerten.
Hintergrund
Militärische Wasserfahrzeuge sind oftmals hochkomplexe Systeme, die für spezifi sche Einsatzzwecke entwickelt wurden und über eine Vielzahl von Komponenten teils unterschiedlicher Hersteller verfügen. Im Vergleich zu zivil genutzten Wasser fahrzeugen zeichnen sich militärische Wasserfahrzeuge oftmals durch eine ver gleichsweise kleine Stückzahl, hohe Komplexität, hohe Anzahl an verwendeten Fahrzeugkomponenten und hohe Schutzbedürftigkeit von fahrzeugbezogenen Da ten aus. Die Zusammensetzung der Fahrzeugkomponenten ist also oftmals sehr heterogen und es ist angesichts der Vielzahl und Integrationsdichte an Komponen ten und Herstellern nicht immer möglich, das Zusammenspiel der einzelnen Kom ponenten für jedes denkbare Einsatzszenario umfassend zu testen. Hinzu kommt die Tendenz der Hersteller der Fahrzeugkomponenten, Messwerte, die durch kom ponenteninterne Sensoren erfasst wurden, geheim zu halten um zu verhindern, dass Dritte dieses Wissen nutzen könnten, um die Fahrzeugkomponente nachzu bauen 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 Schiffs brennkraftmaschine mit einer Steuerungseinrichtung zur Steuerung und/oder Rege lung des Betriebs der Schiffsbrennkraftmaschine. Die Steuerungseinrichtung be stimmt auf Grundlage der Position des Schiffs Sollbetriebsparameter für die Schiffs brennkraftmaschine.
Die deutsche Patentanmeldung DE 102011 086355 A1 beschreibt ein Waffensys tem 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 Bettungs fehler der betreffenden gesteuerten Anlage und/oder der das Steuergerat beauf schlagenden steuernden Anlage auf. Es sind weiter Speicher für die Bettungs fehlerwerte in Abhängigkeit von der Horizontalwinkellage der gesteuerten Anlage und/oder der steuernden Anlage vorgesehen.
Die US-Patentanmeldung US 2008 / 0 120 620 A 1 beschreibt die Verwendung ei ner „offenen Softwarearchitektur“ für die Navy-Flotte.
Die US-Patentanmeldung US2018/0304969A1 beschreibt ein Schiff mit einem Pro peller montiert an einer drehbaren Welle und ein Verfahren zur Umwandlung der Leistung einer rotierenden Welle in Schub um das Schiff über das Wasser zu trei ben. Das Verfahren umfasst die Beschaffung von Messwerten, die für die Wellen leistung beschreibend sind, eine Schätzung zweier überschüssigen Wellenleistun gen 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 Wellenleis tungen.
Die US-Patentanmeldung US2019/0176945A1 beschreibt eine Bewegungssteue rung eines Schiffes in einer Art und Weise, die Leistung und Geräuschemission op timal ausgleicht.
Die US-Patentanmeldung US 2006 / 0058929 A 1 beschreibt ein Verfahren zum Verifizieren eines Kontrollsystems eines Schiffes, in dem das Steuersystem in sei nem Betriebszustand Sensorsignale von Sensoren empfängt und als Antwort Steu ersignale an Aktoren sendet, um eine gewünschte Position, Geschwindigkeit, Kurs oder anderes beizubehalten.
Die US-Patentanmeldung US 2018 / 0356826 A 1 beschreibt ein System und Ver fahren zur Erleichterung von Entscheidungen auf einem Wasserfahrzeug. Das Ver fahren umfasst: Erfassung von Umgebungsdaten der Umgebung, in der sich das Wasserfahrzeug befindet; Erzeugung einer Vielzahl von digitalen Modellen, die je weils eine Auswirkung der Umwelt auf eine entsprechende Fähigkeit des Wasser fahrzeugs modellieren; unter Verwendung der Umweltdaten und der digitale Model le, Modellieren einer Auswirkung der Umgebung auf die Fähigkeiten des Wasser fahrzeugs 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 tabgerufen 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 Wasser fahrzeug 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üh rungsformen 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 Fahrzeugkom ponenten gehören zu einem Waffensystem, einer Antriebseinheit und einem Navi gationssystem. Die Sensoren sind zur Erfassung von Messwerten ausgebildet, wo bei die Messwerte Betriebszustände der Fahrzeugkomponente, die den die Mess werte erfassenden Sensor beinhaltet, und/oder Zustände des Wasserfahrzeugs o- der seiner Umgebung angeben.
Das militärische Wasserfahrzeug beinhaltet ferner eine Datenbank. In der Daten bank ist eine Historie von Messwerten der Sensoren in Verbindung mit einem Zeit stempel persistent und geschützt gespeichert.
Das militärische Wasserfahrzeug beinhaltet ein elektronisches Automatisierungs system. 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. Bei spielsweise können die erfassten Messwerte direkt als Input an das Automatisie rungssystem weitergeleitet werden. Zusätzlich oder alternativ dazu können die Messwerte oder zumindest einige von diesen einem Nutzer angezeigt werden, so- dass dieser auf Basis dieser Messwerte entscheiden kann, wie das Automatisie rungssystem bedient werden muss. Eine erste Verwendung der jeweils aktuell gülti gen Messdaten besteht also in der Beeinflussung der Steuerung der Wasserfahr zeugkomponenten in Echtzeit. Zum anderen werden die Messdaten zusätzlich in einer Datenbank gespeichert. Dies geschieht so, dass der zeitliche Verlauf der Er zeugung 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, auto matisch mit der Zeit eine Datenbasis zu erschaffen, durch deren Analyse komplexe Abhängigkeiten und Wechselwirkungen mehrerer Fahrzeugkomponenten bzw. de ren Zuständen (Temperatur Motor, Drehzahl Turbine, Vibration eines Ruders) unter Berücksichtigung von Umgebungsparametern (Temperatur, Luftfeuchte, Druck, Tie fe, 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 Unberech tigte 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 His torie der von den Sensoren (egal ob in der Automation verfügbar oder nicht) eines Wasserfahrzeugs erfassten digitalen Messwerte. Die Betreiber des Wasserfahr zeugs 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 ver schiedener Hersteller stammen. Da die Messwerte verschiedener Sensoren ver schiedener Fahrzeugkomponenten in einer einzigen Datenbank gespeichert wur den, 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 ein deutig 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 kom plexer 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 Fahrzeugkompo nenten oft gering oder in militärischen Belastungssituationen nicht zuverlässig ab rufbar 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 kompensie ren. 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 Da tenbank bereitgestellt wird. Es ist auch möglich, dass einige oder alle Daten der Da tenbank 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 Containerverwaltungs software die konfiguriert ist zur automatisierten Bereitstellung, Skalierung und Ver waltung („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 Pro gramme, die innerhalb dieses Containers laufen von Programmen, die außerhalb dieses Containers laufen, isoliert. Vorzugsweise orchestriert die Containerverwal tungssoftware mehrere Container auf einem oder mehreren Computern.
Das Wasserfahrzeug umfasst nach Ausführungsformen der Erfindung mehrere zu einem Rechnerverbund miteinander vernetzte Computer und eine Containerverwal tungssoftware. 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 Rechner verbund und die Verwendung einer Containerverwaltungssoftware zur Orchestrie rung 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 paral- leier Zugriff auf identische Kopien der Daten bzw. Analysemodule möglich ist. Dies erhöht im Hinblick auf die Datenbank die Geschwindigkeit von Lese- und Schreib zugriffen auf die in der Datenbank gespeicherten Messwerte und erhöht die Ausfall sicherheit. Im Hinblick auf die gemäß mancher Ausführungsformen redundant be reitgestellten 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 ho her Wichtigkeit, denn ein Ausfall der Datenbank und/oder von Softwareprogram men, die in den Containern instanziiert sind, kann zu einem kritischen Datenverlust, Dateninkonsistenzen oder dem Ausfall von Prognose- und Warnfunktionen auf Ba sis aktuell gespeicherter oder in der Vergangenheit gespeicherten Messdaten füh ren. Außerdem ermöglicht die Verwendung von Containern und der Containerma nagementsoftware zur Orchestrierung der Container eine einfache Skalierung des Systems, z.B. wenn im Laufe der Zeit eine deutlich größere (Mess)datenmenge ge speichert und/oder analysiert werden soll und/oder wenn die Anzahl der Software programme, die auf dem Rechnerverbund instanziiert werden soll, mit derzeit grö ßer wird.
Die Verwendung von Containern für die Bereitstellung und Isolation von Software applikationen gewährleisten die Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen. Die Verwendung von Containern ermöglicht es, eine Appli kation 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 ver einfacht.
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 konfi guriert, dass eine virtuelle Vernetzung zwischen einigen der Containern vorliegt, sodass die in einem Container instanziierten Analysemodule auf den Inhalt von ei ner Datenbanken, die innerhalb von einem mit dem eigenen Container vernetzten Containern instanziiert ist, zugreifen kann. Entsprechende Ausführungsformen kön nen den Vorteil haben, dass ein Nutzer, z.B. über die Containerverwaltungssoft ware, sehr genau und feingranular festlegen kann, welche Analysemodule innerhalb welcher Container auf die Inhalte anderer Container zugreifen können. Beispiels weise 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 Senso ren 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 Compu ternetzwerk bzw. die Container so zu konfigurieren, dass die Analysesoftware A1 des Herstellers H1 in einem dritten Container läuft, der selektiv auf die erste Daten bank im ersten Container zugreifen darf, nicht jedoch auf die Daten der Sensoren des Herstellers H2 in dem zweiten Container. Analog kann die Konfiguration bein halten, 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 Contai ner.
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.) bereitstel len. Oftmals sind Servercomputer gekennzeichnet durch überdurchschnittlich hohe Rechenkapazitäten und/oder überdurchschnittlich hohe Mengen an verfügbarem Arbeitsspeicher. Nach Ausführungsformen der Erfindung 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. Zu sätzlich oder alternativ dazu sind die ein oder mehreren Analysemodule dazu aus gebildet, 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 auszu führen.
Beispielsweise sind die Analysemodule dazu ausgebildet, die in der Datenbank ge speicherte Historie der Messwerte zu analysieren und auf Basis der Analyse Vor hersagen bezüglich des aktuellen und/oder künftigen Zustands des Wasserfahr zeugs oder seiner Komponenten und/oder eine in technischer oder taktischer Hin sicht sinnvolle Aktion zu berechnen. Insbesondere werden gemäß Ausführungsfor men zunächst Flandlungsempfehlungen 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 Umgebungspa rameter (Luftdruck, Wassertemperatur, Tiefe, geographische Position des Fahr zeugs, 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 Histo rie dieser Messparameter erfassbar sind und für eine Vorhersage künftiger Zustän de und Aktionen verwendet werden können.
Die Ausführung der Steuerungs- und/oder Analysefunktion ohne Nutzung einer In ternetverbindung 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äch tigt wird. Im militärischen Kontext ist es von großer Wichtigkeit, dass das Automati sierungssystem 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 Automatisie rungssystem und die Analysemodule so programmiert sind, dass diese unabhängig voneinander arbeiten, also an keiner Stelle das Automatisierungssystem Daten be nö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 Automatisierungssys tem verbundenen Dienst einerseits und durch die ein oder mehreren Analysemodu le andererseits. Beispielsweise kann die operative Entkopplung beinhalten, dass das Automatisierungssystem aktuelle Messdaten von den Sensoren über einen ers ten 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 Sen soren 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 zwei ter Kommunikationskanal bezeichnet werden und z.B. ausgebildet sein als eine Vielzahl von Datenbankverbindungen, die von den Sensoren im Hinblick auf die Da tenbank 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ührungs form beinhaltet das Wasserfahrzeug einen Dienst, über welchen das Automatisie rungssystem Daten aus der Datenbank ausliest und/oder Daten, die von dem Au tomatisierungssystem 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 meh reren Analysemodule andererseits auf unterschiedlichen Computern. Beispielsweise kann die asynchrone Arbeitsweise dadurch realisiert sein, dass das Automatisie rungssystem auf einem oder mehreren ersten Computern gehostet ist und die Da tenbank und die Analysemodule auf einem oder mehreren zweiten Computern. Al ternativ 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 Auto matisierungssystem 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 Ana- lysemodule, die in mehreren unterschiedlichen Containern und damit isoliert vonei nander ausgeführt werden.
Dies kann vorteilhaft sein, da dies die Ausfallsicherheit, Wartbarkeit und Perfor mance 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ög lich, 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 unterge ordneter Bedeutung, ob ein Analysemodul, welches anhand der zurückgelegten Strecke den nächsten routinemäßigen Servicetermin für das Wasserfahrzeug vor hersagt, ausreichend CPU- und Arbeitsspeicher-Kapazität für seine Arbeit zur Ver fü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 Ana lysemodul, das anhand verschiedener material- und strömungsbezogener Messwer te 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 ge trennten Containern voneinander operativ isoliert sind ist im Kontext eines militäri schen Wasserfahrzeugs besonders vorteilhaft: beispielsweise können die Analyse module von verschiedenen Herstellern von Fahrzeugkomponenten stammen. So kann zum Beispiel ein erstes Analysemodul vom Hersteller einer Turbine bereitge stellt werden und dazu ausgebildet sein, Messwerte bezüglich der Drehzahl, Tem peratur und Vibrationsverhalten einer vom gleichen Hersteller stammenden Turbine mit Sensoren für Drehzahl, Temperatur und Vibrationszustand der Turbine zu ana lysieren. Die Analyse kann verschiedenen Zwecken dienen: zum Beispiel, um fest zustellen, ob kritische Systemzustände erreicht wurden, die zum Erlöschen der Her stellergarantie führen und/oder die eine Inspektion oder eine Überholung der Turbi ne erforderlich machen. Die Analyse kann aber auch dazu dienen, zu untersuchen, wie die einzelnen Messwerte voneinander abhängen, also ob die Turbine zum Bei spiel 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 mo torbezogener Messwerte zu analysieren. Die Analyse kann ebenfalls verschiedenen Zwecken dienen wie z.B. der Feststellung des Erreichens oder Überschreitens ei nes 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 einzel nen 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 Analysemo dul 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 Funktions weise der Fahrzeugkomponenten unberechtigterweise in Erfahrung zu bringen. Be stimmte Personen oder Organisationen könnten ein Interesse daran haben zu er fahren, 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 verhin dert werden, dass die einzelnen Analysemodule isoliert voneinander jeweils inner halb 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 Ressourcenver brauch 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 an deren 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 Analysefunk tionalitä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 been den und/oder einen der Container, der eine Instanz dieses Analysemoduls bein haltet, zu löschen oder auf einen anderen Computer zu verschieben; dies kann vorteilhaft sein, da sicherstellt, dass nicht benötigte CPU- und Speicher- Ressourcen automatisch freigegeben werden, wenn sie für analytische Tätigkei ten aktuell nicht mehr benötigt werden; umso schneller können diese freien Res sourcen im Notfall für lebenswichtige Systeme bereitgestellt werden; die „maxi male Zahl“ kann z.B. eine Zahl sein, die in einer Konfiguration der Containerma nagementsoftware manuell oder automatisch spezifiziert wurde. Maximal bedeu tet, 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 mig rieren; 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 Con tainer samt der darin laufende Analysemodulinstanz auf diesen Computer zu mig rieren; 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 be stimmten Analysemoduls beinhaltet), eine Kopie dieses identifizierten Containers samt darin laufenden Analysemodul auf mindestens einem weiteren der Compu ter zu instanziieren; und Analysen unter Einbeziehung zumindest der Analyse modulinstanz 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 pa rallel 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 Con tainer zu löschen; die Containerverwaltungssoftware kann also Downscaling- Funktionen durchführen. Dies kann vorteilhaft sein, da hierdurch der Verbrauch an CPU und Arbeitsspeicher- Ressourcen besser auf die Computer des Rechnerverbunds verteilt und eine besse re Reaktionszeit erreicht werden kann. Außerdem kann eine bedarfsgerechte Ska lierung 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 Fierstellern in einer vertraglichen Beziehung steht, Zu griff auf Messdaten hat, die von Sensoren dieser Fahrzeugkomponente erfasst und gespeichert werden, nicht jedoch auf die Messdaten der Sensoren anderer Fahr zeugkomponenten.
Gemäß eines weiteren Beispiels erfolgt die Zuweisung derart, dass ein Analysemo dul, das von einer bestimmten Firma entwickelt wurde, die auch mehrere Fahrzeug komponenten hergestellt hat oder mit den Fierstellern 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 Analysemo dul, das von einer bestimmten Firma entwickelt wurde, die auch ein oder mehrere Fahrzeugkomponenten hergestellt hat oder mit den Fierstellern dieser ein oder meh reren Fahrzeugkomponenten in vertraglicher Beziehung steht, Zugriff auf die Mess daten 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 Da tenbank gespeichert wurden. Die Analysemodule von Wasserfahrzeugen gemäß Ausführungsformen der Erfin dung können den Messdaten der Datenbank gemäß einer beliebigen Kombination der hier beschriebenen Beispiele sein.
Die verschiedenen Formen der spezifischen Zuweisung von Messdaten und Analy semodulen 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 Herstel ler der jeweiligen Komponente hat den Vorteil, dass wichtige Zustandsparameter der Fahrzeugkomponente wie zum Beispiel Temperatur, Vibrationsverhalten, Belas tungsparameter, 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äl len. 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 ande ren Komponenten oder Umgebungs-Parametern) relevant.
Für den Hersteller einer Fahrzeugkomponente und/oder den Betreiber des Fahr zeugs ergibt sich das Problem, dass die Preisgabe sämtlicher Messwerte gegebe nenfalls 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 Fahrzeugkom ponente offengelegt werden. Dies verhindert gegenwärtig eine Integration der Messdaten der Sensoren in verschiedene Fahrzeugkomponenten, was für den Be treiber militärischer Wasserfahrzeuge in sicherheitstechnischer Hinsicht ein Nachteil ist, denn viele technisch relevante Effekte, wie zum Beispiel ein bestimmtes Verhal ten eines Ruders, einer Turbine oder einer sonstigen komplexen Komponente des Wasserfahrzeugs, ergeben sich erst aus dem komplexen Zusammenwirken mehre- rer Fahrzeugkomponenten, die jeweils unterschiedliche interne Zustände aufweisen können.
Die beschriebene IT-Architektur wonach einzelnen Analysemodulen bestimmte Tei le 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 Lieferan ten 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 vertrau enswürdig angesehen und akzeptiert wurden. Es wird also eine IT-Architektur ge schaffen, die den Herstellern militärischer Fahrzeugkomponenten ermöglicht, sen sible Messdaten auf eine sichere Weise nur an bestimmte Analysemodule zur Ver fügung zu stellen. Das Risiko, dass ein Mitbewerber oder Angreifer die Messdaten verwendet, um eine Fahrzeugkomponente nachzubauen oder anzugreifen kann al so ausgeschlossen werden.
Der Betreiber des militärischen Wasserfahrzeugs profitiert davon, dass die Messda ten einer Vielzahl von Fahrzeugkomponenten gemäß Ausführungsformen der Erfin dung 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 Fahrzeug komponenten allenfalls intern zu erfassen und nur von Fahrzeugkomponenten internen Recheneinheiten zu analysieren, ohne die Messdaten nach außen preiszu geben oder gar über einen längeren Zeitraum zu speichern. Dank der IT-Architektur von Wasserfahrzeugen gemäß Ausführungsformen der Erfindung können die Her steller von Fahrzeugkomponenten nun auf die Komponenten-internen Rechenein heiten zur geheimen Analyse der Messdaten verzichten, da die Messdaten mehre rer Sensoren und Fahrzeugkomponenten zwar in einer Datenbank zentral gespei chert werden, dennoch aber nicht jedes Analysemodul beliebig auf diese Daten zu greifen kann. Einige aktuell verfügbare Automatisierungssysteme für militärische Wasserfahrzeu ge bieten zwar ebenfalls Zugriff auf Sensordaten mehrerer Sensoren, jedoch nur auf die jeweils gültigen Ist-Werte von Einzelsystemen, die nicht oder nur wenig prakti kabel nutzbare historische Profile und Trends der Messwerte über einen längeren Zeitraum enthält. Aufgrund der Echtzeit-Anforderungen an solche Automatisie rungssysteme hatte man bisher davon Abstand genommen, die knappen Ressour cen des Automatisierungssystems von Wasserfahrzeugen durch rechenintensive Analysen umfangreicher historischer Datenbestände zu belasten. Dank der verteil ten Vorhaltung der Analysemodule in mehreren Containern in einem vom Automati onssystem 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 Automatisie rungssystems beeinträchtigt wird. Das Problem, dass Hersteller von Fahrzeugkom ponenten mit integrierten Sensoren die von diesen erfassten Messwerte aus ver schiedenen 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 Daten bank gespeicherten Messwerte zugreift. Dieser indirekte Empfang über die Daten bank hat den Vorteil, dass die Analysemodule keine Schnittstelle aufweisen müs sen, um von einem bestimmten Sensor Messdaten empfangen zu können. Gemäß einer Ausführungsform besitzen die ein oder mehreren Sensoren Schreib rechte 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 nicht flü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 Mess werte zugreifen können.
Nach Ausführungsformen der Erfindung ist zumindest eines der mehreren Analy semodule, 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 Fahrzeug komponente; 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 ei nen kritischen Zustand der einen Fahrzeugkomponente sind; und/oder
- eine Berechnung einer Flandlungsempfehlung an einen Menschen in Bezug auf die eine Fahrzeugkomponente; und/oder
- eine Berechnung eines Steuerbefehls an die eine Fahrzeugkomponente zur au tomatischen Durchführung des Steuerbefehls.
Dies kann vorteilhaft sein, da die ein oder mehreren Analysemodule dazu verwen det werden können, nicht nur retrospektiv einzelne Korrelationen und Zusammen- hänge zu erkennen, sondern auf Basis der in der Datenbank gespeicherten Historie von Messdaten mehrerer Sensoren auch dazu verwendet werden können, tech nisch und/oder taktisch kritische Situationen in oder auf dem Wasserfahrzeug vor herzusagen 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 Au tomatisierungssystem typischerweise wenig flexibel ist, da es typischerweise Mess werte einer vordefinierten Anzahl von Sensoren einer vordefinierten Menge an Fahrzeugkomponenten integriert, ist die Verwendung von Analysemodulen in Er gä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 Fahrzeug komponenten 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üsse lungsschlüssel. Eines der Analysemodule ist der zumindest einen Fahrzeugkompo nente zugeordnet und beinhaltet einen zu diesem kryptographischen Verschlüsse lungsschlü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 asymmet risches kryptographisches Schlüsselpaar handeln, wobei der von dem Sensor ver waltete 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 (Ent schlüsselungsschlüssel) ist. Die Sensoren der zumindest einen Fahrzeugkompo nente 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üs selten Daten zu analysieren.
Gemäß Ausführungsformen der Erfindung haben alle Sensoren, die in oder an der selben Fahrzeugkomponente angebracht sind, den gleichen öffentlichen Verschlüs selungsschlü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 Analyse modulen 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 ge hört vorzugsweise zu einer PKI eines Fierstellers dieser Fahrzeugkomponente. Ei nes der Analysemodule ist der zumindest einen Fahrzeugkomponente zugeordnet und beinhaltet einen zu diesem Signierschlüssel korrespondierenden Signaturprüf schlüssel. Die Sensoren der zumindest einen Fahrzeugkomponente sind dazu aus gebildet, zumindest einige der von ihnen erfassten Messwerte mit dem Signier schlü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 konfigu riert, 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. Insbe- sondere 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 ak tuellen Rotationszahl der Turbine und einem aktuellen Winkel des Steuerruders den künftigen Kurs für die nächsten 5 km vorherzusagen. Ein manipulierter Win kelsensor 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 beho ben werden, dass die Sensoren die von Ihnen erzeugten Messdaten signieren, wo bei 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 Analysemodu- le 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 Hardwarekom ponente 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 integrie ren und hierbei nicht nur aktuelle Messwerte, sondern auch die Historie der Mess werte berücksichtigen können. Da die Analysemodule als einzelne, isolierte Soft ware Module implementiert sind, sind Anzahl und Zusammensetzung der Analyse module leicht an sich im Laufe der Lebenszeit des Fahrzeugs möglicherweise än- dernde Zusammensetzung der Fahrzeugkomponenten anpassbar. Die Analyseer gebnisse der Analysemodule stellen somit eine Quelle für Systemdiagnosen und Steuerbefehle dar, welche die Funktionen des Automatisierungssystems auf beson ders flexible Weise ergänzen. Je nach Art des Analyseergebnisses und Implemen tierung können die Analyseergebnisse Flandlungsempfehlungen an einen Nutzer sein, wobei die Flandlungen von dem Nutzer bzw. manuell ausgeführt werden müs sen. Es kann sich auch um Flandlungsempfehlungen 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 da zu ausgebildet, eine Analyse (z.B. Korrelationsanalyse, Machine-Learning (ML) ba sierten 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 Fahrzeug komponente; und/oder
- eine Vorhersage der Zeit des Eintretens eines kritischen Zustands einer Fahr zeugkomponente; und/oder
- dem automatischen Identifizieren von ein oder mehreren Umgebungs- Parametern und/oder Fahrzeugkomponenten-Parametern, die ursächlich für ei nen 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 For men der Korrelationsanalyse besonders dafür geeignet sind, aus historischen Messwerten mehrerer unterschiedlicher Parameter komplexe, komponentenüber- greifende, lineare wie nichtlineare Abhängigkeiten und Wechselwirkungen zu er kennen 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 meh reren Computern verteilt und/oder redundant gespeichert.
Dies kann vorteilhaft sein, da die Ausfallsicherheit erhöht wird, falls einer der Rech ner ausfällt oder nicht erreichbar ist. Außerdem erlaubt eine redundante Speiche rung parallelen Zugriff auf Kopien der gleichen Daten und damit eine Beschleuni gung 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 meh reren 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 wel chem eine Kopie derjenigen Teile der Daten, die in dem ausgefallenen Computer gespeichert waren, identifiziert wird, und die auf diesem anderen Computer ent haltenen Daten den Analysemodulen und der Automatisierungssystem bereitge stellt werden (z.B. durch Starten dieses anderen Computers, Freigabe eines Zu griffs 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 wiederherge stellt 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 ko pieren; hierfür können z.B. Load-Balancing-Funktionen wie sie z.B. in der Soft ware Kubernetes bereits enthalten sind verwendet werden.
Dies kann aus analogen Gründen wie die redundante Instanziierung der Analyse- module auf mehreren Computern vorteilhaft sein. Insbesondere wird die Verfügbar keit 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 feu erfest und/oder druckwellen-robust und/oder wasserdicht ist.
Beispielsweise kann der Sicherheitsbehälter aus einem einwandigen oder vorzugs weise 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. Laufzeit umgebungen 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 Rechnernetz werks ein oder mehrere erste Rechner und ein oder mehrere zweite Rechne. Die ersten Rechner und die zweiten Rechner sind in unterschiedlichen räumlichen Be reichen des Wasser-fahrzeugs untergebracht, wobei die unterschiedlichen räumli chen Bereiche unterschiedliche Zimmer, unterschiedliche Decks, unterschiedliche durch wasserdichte Schleusentore getrennte Kammern, Steuerbordseite und Back bordseite des Wasserfahrzeugs oder Bugseite und Heckseite des Wasserfahrzeu ges sind.
Dies kann vorteilhaft sein, da die Ausfallsicherheit des Wasserfahrzeuges und der Analysemodule erhöht wird: sollten wegen einer Detonation oder einer Havarie be stimmte Bereiche des Schiffs beschädigt werden, sind davon nicht alle Analysemo dule betroffen. Vielmehr kann die Containerverwaltungssoftware auf den Contai nern.
In einem weiteren Aspekt betrifft die Erfindung ein System umfassend mindestens zwei militärische Wasserfahrzeuge gemäß einer der hier beschriebenen Ausfüh rungsformen oder Beispiele und ein Computersystem. Das Computersystem bein haltet eine Schnittstelle zum sicheren Import des Inhalts der Datenbanken der min destens zwei Wasserfahrzeuge. Das Computersystem beinhaltet außerdem eine Flottenanalysesoftware. Die Flottenanalysesoftware ist dazu ausgebildet, die Mess werte 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 Fahr zeugkomponenten im besten oder schlechtesten Zustand ist im Hinblick auf zu mindest ein technisches Bewertungskriterium (z.B. Füllstand Tank, Verfügbarkeit von Energieressourcen, Zeit bis zur nächsten Wartung, Indikator der Ausfallsi cherheit, Indikator der Geeignetheit des Wasserfahrzeug für bestimmtes Einsatz szenario; ); und/oder - eine Erkennung kritischer Zustände von einer Fahrzeugkomponente in einem oder mehreren der Wasserfahrzeuge; beispielsweise kann durch Analyse histori scher Messdaten in den Datenbanken der mehreren Wasserfahrzeuge erkannt werden, dass bei einigen wenigen Wasserfahrzeugen eine Kombination aus An stellwinkel des Ruders und der Drehzahl der Turbine, die bei der Mehrzahl der Wasserfahrzeuge unproblematisch war, einen instabilen Zustand des Wasser fahrzeugs bewirkt hat, die manuelles Eingreifen erforderlich gemacht hat, sodass diese wenigen Fahrzeuge zur Inspektion gebracht werden sollten; bestimmte Vib rationsmuster 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 Fahr zeugkomponente 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 Fahr zeug, 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 ei nen kritischen Zustand einer der Fahrzeugkomponenten in einem oder mehreren der Wasserfahrzeuge sind; beispielsweise kann die Flottenanalysesoftware er kennen, dass nur diejenigen Schiffe, die in Gewässern mit einer Wassertempera tur von unter 6 °C unterwegs waren, Probleme mit dem Auslösen einer Bewe gung bei einem bestimmten Bauteil hatten, sodass die Vermutung naheliegt, dass die Materialkontraktion bei niedrigen Temperaturen Auslöser für die Prob leme war und das Bauteil nicht geeignet für den Einsatz bei niedrigen Temperatu ren ist. Die Analyse mehrerer Wasserfahrzeuge kann es hier ggf. ermöglichen, Bl
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 Applikati onsprogramm handeln oder um eine Kombination mehrerer einzelner Analysepro gramme, 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ön nen.
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 Flersteller(n) der Fahr zeugkomponenten oder der Wasserfahrzeuge bereitgestellt werden, falls die Fier steller diese Schlüssel für den Kunden, also den Betreiber des Wasserfahrzeugs, freigeben.
Unter einem „militärischen Wasserfahrzeug“ wird hier ein Wasserfahrzeug verstan den, das dazu ausgebildet ist, von Streitkräften zur Erfüllung ihrer Aufgaben ver wendet 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 Fahr zeuge, die zur Fortbewegung auf dem oder im Wasser bestimmt sind. Insbesondere kann es sich um ein windbetriebenes oder ein maschinenbetriebenes Wasserfahr zeug handeln, z.B. Segelschiffe, Luftkissenboote, Tragflächenboote, Untersee- Boote, Fregatten, Flugzeugträger, Versorgungsschiffe, etc. Beispielsweise können manche Fregatten zur Seeraumüberwachung, Ubootjagd, Bekämpfung von Über wassereinheiten und Abwehr von Luftangriffen auf das eigene Schiff bzw. den Ver band ausgebildet bzw. ausgerüstet sein. Versorgungsschiffe sind dazu ausgebildet, Einsatzgruppen der Marine, die sich aufgabenorientiert aus unterschiedlichen Schif fen und Booten zusammensetzen können, zu unterstützen. Die logistische Haupt aufgabe eines Versorgungsschiffes besteht in der Versorgung mit Betriebsstoffen, Verbrauchsgütern, Proviant und Munition. Dabei kann ein Versorgungsschiff durch- aus auch mit einem Waffensystem versehen sein, z.B. um feindliche Übergriffe ab zuwehren.
Unter einer „Fahrzeugkomponente“ wird hier ein Teil des Wasserfahrzeugs verstan den, das in seiner Gesamtheit zumindest eine bestimmte Funktion erfüllt. Eine Fahrzeugkomponente kann ein Bauteil, also ein Einzelteil eines technischen Kom plexes sein, oder ein System aus mehreren Bauteilen, die in Ihrer Gesamtheit diese Funktion erfüllen. Typischerweise werden alle Bestandteile einer bestimmten Fahr zeugkomponente als Einheit in ein Fahrzeug verbaut. Beispielsweise können eine Ruderanlage, eine Radaranlage, ein Waffensystem, eine Motoreinheit, eine Steuer einheit etc. jeweils eine Fahrzeugkomponente darstellen.
Unter einem „Sensor“, auch als Detektor, (Messgrößen- oder Mess-)Aufnehmer o- der (Mess-)Fühler bezeichnet, ist ein technisches Bauteil, das bestimmte physikali sche oder chemische Eigenschaften (physikalisch z. B. Wärmemenge, Temperatur, Feuchtigkeit, Druck, Schallfeldgrößen, Helligkeit, Beschleunigung oder chemisch z. B. pFI-Wert, lonenstärke, elektrochemisches Potential) und/oder die stoffliche Be schaffenheit 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 wei terverarbeitbare elektrische Signal insbesondere datentechnisch verarbeitbare Da ten 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 Wehr material, insbesondere militärisches Großgerät, verstanden. Ein Bestandteil des Waffensystems ist die eigentliche Waffe. Beispielsweise kann ein Kriegsschiff Waf fen in Form von Luftabwehrflugkörpern in innerhalb eines als Nahbereichsverteidi gungssystem ausgebildeten Waffensystems beinhalten. Insbesondere kann ein Waffensystem ein Verbund einzelner technischer Elemente sein, welche unterei- nander 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 ei ner 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 Flugab wehrraketensystem ist ein weiteres Beispiel für ein Waffensystem. Die verschiede nen 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 autono mes System) und Geoinformationen (Topologie-, Straßen-, Luft- oder Seekarten) eine Zielführung zu einem gewählten Ort oder eine Route unter Beachtung ge wü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 Umdre hung 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 Datenbankmanagementsys tem (DBMS) verwaltete Datenstruktur. Ein DBMS ist ein System zur elektronischen Datenverwaltung, das dazu ausgebildet ist, große Datenmengen effizient, wider spruchsfrei und dauerhaft zu speichern und benötigte Teilmengen in unterschiedli chen, bedarfsgerechten Darstellungsformen für Benutzer und Anwendungspro gramme bereitzustellen. Zur Abfrage und Verwaltung der Daten bietet ein Daten banksystem eine Datenbanksprache an. Die Datenbank kann eine relationale Da tenbank sein. Die Struktur der Daten wird durch ein Datenbankmodell festgelegt.
Unter einer „Historie von Messwerten“ wird hier eine Datenmenge verstanden wel che den zeitlichen Verlauf mehrerer Messwerte spezifiziert.
Unter einem „Zeitstempel“ wird hier ein Datenwert verstanden, der einen bestimm ten Zeitpunkt spezifiziert, z.B. den Zeitpunkt (Datum und Uhrzeitangabe) wann ein bestimmter Messwert erfasst wurde. Vorzugsweise werden Zeitstempel in der koor dinierten 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 ei nem Programm gelesen werden können, das einen geeigneten Entschlüsselungs schlü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" be zeichnet werden. Echtzeit-Antworten werden oft in der Größenordnung von Millise kunden 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 an gegeben werden können.
Unter einem „Host“ oder „Host-Com puter“ wird hier ein Computer verstanden, der allein oder in Interoperation mit einem oder mehreren weiteren Computern ein be stimmtes 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 Pro gramme 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 ver waltet 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 virtu elle 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 Contai ner, die alle nötigen Pakete enthalten, leicht als Dateien transportieren und installie ren lassen. Docker packt die Anwendung und alle für deren Ausführung benötigten System komponenten 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 ska lieren lässt.
Containervirtualisierung ist eine Methode, um mehrere Instanzen eines Betriebssys tems (als sog. „Gäste“) isoliert voneinander auf einem Hostsystem zu betreiben. Im Gegensatz zur Virtualisierung mittels eines Hypervisors auf der Basis mehrerer vir tueller Maschinen hat Containervirtualisierung zwar einige Einschränkungen in der Art ihrer Gäste, gilt aber als besonders ressourcenschonend. Containervirtualisie rung basiert auf mehreren Prinzipien, die in einzelne Softwareprodukten zur Contai nervirtualisierung unterschiedlich implementiert sind. Ein Kern davon ist jedoch im mer ähnlich: mehrere Container nutzen einen Kernel gemeinsam und isolieren zu mindest einige der verwendeten Betriebssystemmittel voneinander.
Beispielsweise kann das Open-Source-Programm Kubernetes als Containerma nagementprogramm verwendet werden. Bei Kubernetes handelt es sich um eine Software zur Container-Orchestrierung, die es ermöglicht, Anwendungen auf einfa che und effiziente Weise über mehrere Hosts zu orchestrieren. Kubernetes ermög licht 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 Ma schinen zusammengefasst und als Einheit verwaltet. Kubernetes definiert ein Con tainer 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 Plattform- agnostisch: neben bzw. anstelle von Docker können auch andere Plattformen mit entsprechenden Shims, wie z. B. CRI-0 oder KataContainers verwendet werden.
Unter einer „Containerverwaltungssoftware“ wird hier eine Software verstanden, die konfiguriert ist zur automatisierten Bereitstellung, Skalierung und Verwaltung („Or chestrierung“) 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 Containerverwaltungssoft ware verwendet werden.
Unter einem „Analysemodul“ wird hier eine Software verstanden, die dazu ausgebil det ist, mittels einem oder mehrerer unterschiedlicher rechnerischer Verfahren Messdaten von einem oder mehreren Sensoren so zu verarbeiten, dass eine Ant wort auf eine analytische Fragestellung erzeugt wird. Die Software kann ein Skript, ein komplexes Applikationsprogramm, eine Programmbibliothek oder eine Kombina tion von zwei oder mehreren der vorgenannten Möglichkeiten sein. Das rechen technische 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 Re chenverfahren sein. Das rechnerische Verfahren kann auch ein Verfahren sein, welches nur implizit formuliert ist, z.B. in Form des im Zuge eines Trainingsprozes ses erstellten mathematischen Modells eines Machine-Learning-Programms. Bei spielsweise kann das Modell in der Netzwerkarchitektur und den Gewichten von Netzwerkknoten eines neuronalen Netzwerks spezifiziert sein. Die analytische Fra gestellung kann verschiedene Fragen betreffen, z.B. eine Frage nach dem aktuellen oder für die Zukunft vorhergesagten Zustand einer Fahrzeugkomponente (Parame ter für Vibration, Leitfähigkeit, Elastizität etc. zeigen kritischen Verschleißzustand an?), oder eine Frage beim Zusammentreffen welcher Messparameterwerte ein kri tischer 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 Fahrzeug komponente 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 ei nem ö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 wich tig, dass ein öffentlicher Schlüssel eindeutig einer bestimmten Entität, z.B. einem Benutzer oder einem Analysemodul, zugeordnet werden kann. Um einen Geheim text 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üs sel nicht aus dem öffentlichen abgeleitet werden kann.
Unter einem „Automatisierungssystem“ wird hier ein System zur vollautomatischen oder semiautomatischen Steuerung eines Wasserfahrzeugs verstanden. Die Steue rung erfolgt mittels festgelegten Regeln auf Basis von aktuellen Messwerten von ein oder mehreren Sensoren, die vom Automatisierungssystem in Steuerbefehle umge setzt 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 ge nannt, 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 Con tainern 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 Bereitstel lungsfunktion von Analyseergebnissen können die Computer auch als „Server“ be zeichnet werden.
Kurze Beschreibung der Zeichnung
Nachfolgend werden Ausführungsformen der Erfindung mit Bezug auf die Zeich nung 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 Daten banken 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 betriebe nen 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 Dreh zahl einer Welle, die mechanisch an das Getriebe gekoppelt ist.
Zu den Fahrzeugkomponenten des Wasserfahrzeugs gehört auch ein Navigations system 106 mit einem GPS Sensor 114 zur Bestimmung der aktuellen Position des Fahrzeugs sowie ein Ruder 108 mit einem Lage- oder Winkelsensor zur Bestim mung des aktuellen Winkels des Ruders relativ zur Längsachse des Wasserfahr zeugs. 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 auto matisch und vorzugsweise kontinuierlich oder wiederholt Fahrzeugs- und Umge bungsparameterwerde. Zu diesen Parametern gehören z.B. Luftdruck, Luftfeuchtig keit, 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 Kon trolle von internen Zuständen des Wasserfahrzeugs sowie zur Steuerung der Be wegung 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 Nut zeroberflä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 Mess daten an, die mit einem Zeitstempel versehen werden, welcher die Zeit der Erzeu gung 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 Daten bank, oderz.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 be schrieben.
Das Wasserfahrzeug beinhaltet außerdem eine Waffensystem 102, welches eben falls 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 potenti elle Gefahr darstellt, ist ein sicherer Betrieb des Automatisierungssystems von be sonders hoher Bedeutung. Ein „sicherer Betrieb“ bedeutet hier, dass das Automati sierungssystem 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 Was serfahrzeug mit einer Ruderanlage, insbesondere einer Doppelruderanlage han deln. 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 Überwa- chung 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 Sys temkomponenten, z.B. des Waffensystems. Die Ursachen für eine asynchrone Be fehlsweiterleitung und/oder Umsetzung könnten vielfältig sein und auf komplexe Weise Zusammenwirken: Unterschiedliche Gleiteigenschaften der Ruderschäfte, alternde Potentiometer in entsprechenden Schaltungen, unterschiedliche Steuer drü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 unter schiedliche 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 Steuersys tems 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 opti onal 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 Auf nahmefrequenz des Sensors auch dynamisch an die Gegebenheiten angepasst werden, z.B. Erhöhung der Messfrequenz bei Änderung eines oder mehrerer rele vanter Parameter über einen vordefinierten Grenzwert. Der Zeitstempel kann z.B. den Zeitpunkt angeben wann ein Messwert in die Datenbank gespeichert wird, wo bei dieser Zeitpunkt sehr nahe am Zeitpunkt der Messwerterfassung liegt und daher auch diesen Zeitpunkt zumindest näherungsweise repräsentiert. Auch die Positi- onsdaten 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 Steuer befehle einnehmen sollen.
Zusätzlich zu diesen „Ruderanlage-Parameter“ erfassen mehrere weitere Sensoren innerhalb oder außerhalb der Ruderanlage Umgebungsparameterwerte, z.B. Ge schwindigkeit des Schiffes, Wassertemperatur und/oder Wassertiefe und/oder Be triebszustände weiterer Fahrzeugkomponenten, z.B. eines Pumpsystems. Sollte zum Beispiel die Geschwindigkeit des Schiffes (gemessen z.B. in Metern zurückge legter Strecke pro Sekunde) nicht zur Verfügung stehen, können alternativ die An triebsleistung und/oder Turbinendrehzahl als Indikator der Geschwindigkeit verwen det 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 Steuer befehle 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 Zeit punkten 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 betroffe nen Rudern umgesetzt wurde. Die ermittelten Zeiten werden von dem Analysemo dul dazu verwendet, das Senden der Steuerbefehle und/oder den Inhalt der Steuer befehle so anzupassen, dass die Synchronisation der Ruder der Ruderanlage ver bessert 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 Ruder position von der Soll-Position, um zu ermitteln, ob und wann ein Ruder eine ge wü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äß bevorzug ter Ausführungsformen in Echtzeit, anzupassen. Eine Vorhersage von Asynchronitä ten erlaubt es außerdem, notwendige Wartungsarbeiten vorherzusagen und erleich tert die diesbezügliche Planung.
Das Analysemodul für die verbesserte Steuerung der Ruderanlage kann z.B. an hand der Beschleunigungs- bzw. Vibrationsdaten mögliche Ursachen für Asynchro nitäten identifizieren und an einen Nutzer ausgeben. Hierbei werden jedoch nicht nur die Beschleunigungsdaten (SchwingungenA/ibrationen), sondern auch die an deren Ruderanlage-Parameterwerte und Umgebungsparameterwerte in der Analyse berücksichtigt. Dies kann vorteilhaft sein, da auftretende Schwingungen und Vibrati onen stark von der Wassertiefe, Ruderlage, Seegang, Bewuchs, Schaltungszustän den der Ruderanlage und von der Schiffsgeschwindigkeit abhängen. Ohne Berück sichtigung des Kontexts sind die Beschleunigungsdaten daher oftmals nicht ausrei chend 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 Be schleunigungsdaten in Kombination mit den weiteren Ruderanlage-Parametern und Umgebungsparametern ermöglicht es dagegen, Schwingungszustände zu identifi zieren, 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 Steuerein- heit ist dazu ausgebildet, die Lage und Bewegung der steuerbordseitigen und back bordseitigen 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 um fassen: 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, Schal tungszustä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 Um gebungs-Parameterwerte sowie Zeitdauern zwischen einem Senden der Steuerbe fehle von der Steuereinheit an die jeweiligen Ruder bis zur Umsetzung der Steuer befehle zu analysieren, um Korrelationen zwischen den Zeitdauern, den Ruderanla ge-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 Ruderan lage dazu ausgebildet sein, automatisch festzustellen, dass bei dem gegebenen Seegang und Bewuchs der Befehl an die steuerbordseitigen Ruder 400 Millisekun den früher gesendet werden muss als der zu diesem korrespondierende Steuerbe fehl 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 besag ten 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 Steu erbefehle von der Steuereinheit an die jeweiligen Ruder bis zur Umsetzung der Steuerbefehle und zusätzlich Zustands- und/oder Vibrationsparameterwerte zu ana lysieren, die von Sensoren anderer Fahrzeugkomponenten, insbesondere des Mo tors und/oder des Getriebes und/oder einer Radaranlage, erfasst wurden, um Korre lationen zwischen den Zeitdauern, den Ruderanlage-Parameterwerten, den Umge bungs-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 Fahrzeugkompo nenten 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 ne gativen 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. Bei spielsweise kann eine der Logikregeln beinhalten, dass ein Verbrennungsmotor sich nur starten lässt, wenn mindestens ein Abgasweg geöffnet ist. Bei jedem Startvor gang 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 - abgebro chen.
Beispiel 2: Verbesserte Erkennung und Vorhersage von Verbrauch und Zuständen
Umgebungsparameter und zustandsbezogene Parameter von Fahrzeugkomponen ten 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 Diesel motoren werden stärker belastet. Dies hat dann wiederum Auswirkungen auf War tung 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 wer den 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 Fahrzeugkom ponenten 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 konfi guriert, den aktuellen oder künftigen Energieverbrauch und/oder den aktuellen oder künftigen Verschleißgrad einer Fahrzeugkomponente in Abhängigkeit von der Tem peratur 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 Messda ten und/oder sonstiger Leistungsparameter des ganzen Wasserfahrzeugs so zu be rücksichtigen, dass nur vergleichbare Betriebsmodi des Fahrzeugs miteinander ver glichen werden.
Nach Ausführungsformen ist das eine Analysemodul dazu konfiguriert, die zu ver schiedenen Zeitpunkten gemessene Temperatur dazu zu verwenden, auch automa tisch 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, Messda ten und/oder sonstige Leistungsparameter des ganzen Wasserfahrzeugs so zu ana lysieren, dass nur vergleichbare Betriebsmodi des Fahrzeugs miteinander vergli chen werden, um insbesondere den künftigen Energieverbrauch, die aktuell maxi- mal 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. redun danten Fahrzeugkomponenten bei welchen Situationen verwendet werden und/oder wie hoch die Auslastung verschiedener Fahrzeugkomponenten bei unterschiedli chen Bereitschafts- und Nutzungszuständen ist) kann sowohl die Inbetriebnahme ais auch die Nutzungsphase verschiedener Fahrzeugkomponenten verbessert wer den. Diese Erkenntnisse können es ermöglichen, automatisch oder manuell die Be triebsmodi einzelner Fahrzeugkomponenten zu optimieren oder die technischen Eigenschaften einer (neuen) Fahrzeugkomponente zu verbessen.
Beispiel 3: Fahrzeuqüberqreifende Analysen
Die Erfassung und Speicherung einer Vielzahl an Messwerten über längere Zeit räume hinweg (Messwerthistorie) gemäß Ausführungsformen der Erfindung hat be reits auf der Anwendungsebene erhebliche Vorteile.
Weitere erhebliche Vorteile ergeben sich für Systeme, gemäß welchen die Mess- wert-Flistorien 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 Analyse modul 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 Fiersteller 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 ver wenden verschiedene Fiersteller von bestimmten Fahrzeugkomponenten die glei chen, von einem Zulieferer gestellten Bauteile. Durch Import der Datenbanken mit den Messwert-Historien mehrerer Wasserfahr zeuge 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 Heimatha fen in die zentrale Datenbank importiert und von der Datenbank des Wasserfahr zeugs gelöscht werden. Dies erhöht die Datensicherheit und reduziert den Spei cherbedarf der Datenbank des Wasserfahrzeugs.
Die verschiedenen Datensätze können mehrfach dienlich sein. Die Flottenanaly sesoftware 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 Fahrzeugkom ponenten eines bestimmten Typs oder Herstellers im Hinblick auf ein oder mehrere Leistungsparameter besser oder schlechter sind als funktionsgleiche Fahrzeugkom ponenten 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, Verbesse rungen für eine bestimmte Fahrzeugkomponenten sowie typgleiche oder typähnli che 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 Wasserfahr zeug der hier beschriebenen Ausführungsformen. Vorzugsweise gehören die Was serfahrzeuge alle zum gleichen oder zu einem ähnlichen Fahrzeugtyp. Es ist jedoch auch möglich, dass die Wasserfahrzeuge zu unterschiedlichen Fahrzeugtypen ge hören, auch in diesem Fall kann eine Auswertung der Sensordatenhistorien für mehrere Wasserfahrzeuge vorteilhaft sein, z.B. wenn die Fahrzeuge unterschiedli chen Typs einige oder mehrere Fahrzeugkomponenten des gleichen Typs beinhal ten, 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 ein zelner 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 techni sche und/oder organisatorische Sicherheitsvorkehrungen getroffen, um sicherzu stellen, 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 ei ne 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 siche ren 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 Flottenanaly sesoftware 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 relationa len Datenbank auf dem Computersystem 134 gespeichert und dort analysiert wer den. 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 Fahrzeugkom ponente ein Parameterwert „Temperatur“ stammt, denn ein Vergleich ist in der Re gel nur dann sinnvoll, wenn die Messwerte von Sensoren und Komponenten glei chen oder ähnlichen Typs stammen, also z.B. nur die Temperaturwerte für die Komponente „Motor“ miteinander verglichen werden. Vorzugsweise wird auch der Fiersteller bei der Analyse miteinbezogen. Es kann z.B. sein, dass unterschiedliche Fiersteller 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 Fierstel ler bzw. sonstiger relevanter Umstände dazu beitragen, falsche Analyseergebnisse aufgrund einer fehlerhaften Interpretation kleinerer herstellerbedingter Messwertab weichungen erzeugt werden.
Im Zuge der Analyse erkennt die Flottenanalysesoftware dasjenige der Wasserfahr zeuge anhand der importierten Messdaten, welches oder welche der Wasserfahr zeuge im FHinblick auf zumindest ein bestimmtes Zielkriterium optimal oder am schlechtesten beschaffen sind. Bei dem Zielkriterium handelt es sich um ein techni sches 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 Inspek tion. Zusätzlich oder alternativ dazu erkennt die Flottenanalysesoftware kritische Zustände von Fahrzeugkomponenten in einem oder mehreren der Wasserfahrzeu- ge. Beispielsweise kann die Flottenanalysesoftware all diejenigen Fahrzeuge identi fizieren, in welchen Vibrationsparameter darauf hindeuten, dass innerhalb der letz ten 6 Monate in einem Motor z.B. aufgrund von Materialermüdung oder anderer un gü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 Zeit punkt sein, an welchem Energie-, Sauerstoffgas-, oder Lebensmittelvorräte zur Nei ge 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 Fahr- zeugkomponenten-Parameter und deren entsprechende Parameterwertebereiche zu identifizieren, die ursächlich für einen kritischen Zustand einer der Fahrzeug komponenten in einem oder mehreren der Wasserfahrzeuge sind. Dies ist ein be sonders vorteilhafter Aspekt gerade im Kontext hoch komplexer militärischer Was serfahrzeuge: bisweilen sind Fahrzeugkomponenten und Bauteile schon deutlich vor dem erwarteten, normalen Lebenszeitende defekt, ohne dass hierfür eine ein deutige Ursache zu erkennen ist. Bisweilen ist auch zu beobachten, dass ein be stimmtes Bauteil in einem bestimmten Wasserfahrzeug immer wieder versagt wäh rend 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 Vibrati onsverhalten räumlich benachbarter Bauteile, dem Seegang, Wind und Strömungs bedingungen denen das Fahrzeug im Rahmen seines Einsatzes ausgesetzt ist und nicht zuletzt auch von manuell eingegebenen Steuerbefehlen der Besatzung. Ange sichts dieser Komplexität ist es oft nicht möglich, konkrete Ursachen für den Ausfall von Komponenten durch genaue Inspektion eines bestimmten Fahrzeugs zu identi fizieren. Erst durch eine Analyse einer Vielzahl von Messwerten, die über einen län geren Zeitraum von den Sensoren einer Vielzahl von Wasserfahrzeugen erfasst und gespeichert wurden, ist es möglich, den Ausfall bestimmter Bauteile mit dem Zu sammenwirken mehrerer anderer Faktoren zu korrelieren, zum Beispiel einer be stimmten Fahrweise, einer bestimmten Lufttemperatur, eines bestimmten Salzge halts, bestimmten Strömungsverhältnissen und der Verwendung bestimmter weite rer Bauteile und Fahrzeugkomponenten anderer Hersteller. Somit ermöglicht die Flottendiagnose eine verbesserte Fehlerdiagnose aufgrund einer breiteren Daten basis einschließlich der Erkennung von Fehlern, die in höchst komplexer, oftmals nichtlinearer Weise durch Zusammenwirken mehrerer spezifischer Faktoren verur sacht 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 funk tional ü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 soge nannter 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 Con tainers 214, das Analysemodul AM3 nur in Form einer einzigen Instanz 264 in Con tainer 216, und Analysemodul AM4 nur in Form einer einzigen Instanz 268 in Con tainer 222. Manche Analysemodule können aber auch in mehreren Instanzen inner- halb einer entsprechenden Anzahl an Containern ausgeführt werden. Beispielswei se 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 Containerverwal tungssoftware 256 gesteuert. Die Software 256 orchestriert die Instanziierung, Mig ration und Schließung von Containern und darin enthaltenen Analysemodulen dy namisch 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 Wasserfahr zeugs 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 gespei chert. Im Stand der Technik sind verschiedene Verfahren zur verteilten, redundan ten Speicherung von Daten bekannt, zum Beispiel die Speicherung mittels Fehler korrekturverfahren unter Verwendung von Fehlerkorrekturbits. In manchen Ausfüh rungsformen 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 Prozesso ren 282, Arbeitsspeicher 284 und eine Automatisierungssoftware 286. Die Automa tisierungssoftware ist dazu konfiguriert, aktuell erfasste Messdaten von zumindest einigen der Sensoren dynamisch zu empfangen und diese, gegebenenfalls zusam men mit von einem Nutzer eingegebenen Befehlen, als Input zu verwenden, um ein oder mehrere Steuerbefehle aus diesem Input abzuleiten und auf Basis der Steuer befehle 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 Da tenkommunikationskanal 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 ver wendet werden können.
Beispielsweise kann das Antriebssystem 104 von einem ersten Hersteller H1 her gestellt 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 Ent schlüsselungsschlüssel 344 und einem dazu korrespondierenden öffentlichen Ver schlüsselungsschlüssel 332. Vor Auslieferung des Analysemoduls AM4 an den Be treiber oder Hersteller des militärischen Wasserfahrzeugs 100 wird der geheime kryptographische Entschlüsselungsschlüssel 344 so in dem Analysemodul AM4 in tegriert, dass er nicht von unberechtigten Dritten ausgelesen werden kann. Außer dem 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 ein zelnen Sensor einer Fahrzeugkomponente spezifisch erstellt werden. In anderen Ausführungsformen ist es jedoch auch möglich, dass sich alle Sensoren einer Fahr- zeugkomponente 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 sensor individuelle Erzeugung von Schlüsselpaaren hat den Vorteil einer sehr feingranula- ren Steuerung der Zugriffsrechte. Eine fahrzeugkomponenten-individuelle Erzeu gung von Schlüsselpaaren und die Verwendung des gleichen öffentlichen Schlüs sels durch die Sensoren der gleichen Fahrzeugkomponente hat den Vorteil der ver einfachten 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 Fierstellers H2 zugewiesen ist, zu ver schlüsseln, sodass dieses Analysemodule AM3 die Kopien mit seinem korrespon dierenden privaten kryptographischen Schlüssel 342 entschlüsseln kann. Beispiels weise können vertragliche Vertrauensbeziehungen zwischen Fiersteller FH 1 und Fier steller FH2 des Ruders 108 bestehen, sodass der Sensor 112 des Antriebssystems die von ihm erfassten Messwerte nicht nur mit dem öffentlichen Schlüssel 332, son dern in Kopie auch mit dem öffentlichen Schlüssel 330 verschlüsselt, sodass nicht nur Analysemodul AM4 sondern auch Analysemodul AM3 auf diese Messwerte zu greifen und entschlüsseln kann.
In analoger Weise kann die Fahrzeugkomponente 110, die einen Temperatursensor 120 und einen Drucksensor 118 beinhaltet, von einem dritten Fiersteller FH3 herge stellt werden. Der Fiersteller FH3 entwickelt außerdem die Analysemodule AM5 und AM6, die in mehreren Kopien auf dem Computersystem 126 instanziiert sein kön- nen. 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 Ko pien 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 ent hä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 unterschiedli chen Typs, darunter der Winkelsensor 114. Jedem der Sensoren ist ein öffentlicher Schlüssel 326-330 zugeordnet, der mit einem korrespondierenden privaten Schlüs sel 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. Analy semoduls AM1 kann nur diejenigen Daten entschlüsseln, die mit dem öffentlichen Schlüssel 326 verschlüsselt wurden. Analysemoduls AM2 kann nur diejenigen Da ten 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 Was serfahrzeuge sehr vorteilhaft, denn oftmals ist erst eine Kombination bestimmter Daten sicherheitskritisch, nicht einzelne Datenwerte. Beispielsweise sind GPS Posi tionsdaten in jedem Fall sicherheitskritisch, denn sie erlauben es gegnerischen Ein heiten, einen Angriff auf das Wasserfahrzeug einzuleiten. Die Position des Wasser fahrzeugs 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. Aller dings 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üs selung verwendet hat.
Nach Ausführungsformen verfügt eine einzelne besonders vertrauenswürdige Soft ware über eine Kopie aller privaten Schlüssel der Analysemodule. Beispielsweise kann die besonders vertrauenswürdige Software ein weiteres Analysemodul mit er weiterter 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 einzel nen 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 krypto- graphische Schlüsselpaare den Sensoren und Analysemodulen zugeiwesen, aller dings zum Zwecke der Signaturprüfung (hier nicht dargestellt). In diesem Fall wer den private Signierschlüssel den einzelnen Sensoren oder den diese Sensoren be inhaltenden Fahrzeugkomponenten zugewiesen. Die Sensoren oder Fahrzeugkom ponenten verwenden die Signierschlüssel, um die erfassten und optional verschlüs- selten Messdaten zu signieren. Die einzelnen Analysemodule haben Zugriff auf öf fentliche 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 Messda ten mit Signaturprüfschlüsseln zu prüfen, und die Messdaten nur dann weiterzuver arbeiten 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 vorzugswei se mit einem oder mehreren verschiedenen kryptographischen Schlüsseln ver schlüsselt sind, z.B. gemäß eines im H inblick auf Figur 3 beschriebenen Verschlüs selungsverfahrens. Die Box 406 repräsentiert eine Vielzahl unterschiedlicher Mess werte von unterschiedlichen Sensoren verschiedener Fahrzeugkomponenten. Bei spielsweise können die Messwerte von folgenden Fahrzeugkomponenten und Sub systemen stammen: diverse interne Messdaten (z.B. zustandsbezogene Messwerte verschiedener Fahrzeugkomponenten), SBM (schadensbezogene Messdaten, z.B. bezüglich Schäden nach Flavarie 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 Maschi nen 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 Analy- semodule anzeigt, um dem Nutzer zu ermöglichen, geeignete Maßnahmen zu er greifen.
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 die ser selbst geeignete Maßnahmen ergreifen kann, z.B. rechtzeitig einen Hafen an steuern 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 spezifizier ten Daten wie zum Beispiel gewählter Route für die nächsten Tage die voraussicht liche Reichweite der Energievorräte Vorhersagen. Für den Fall, dass die Berech nung ergibt, dass bei der aktuell gewählten Route die Energievorräte nicht ausrei chen, bei Wahl einer alternativ möglichen Route die Vorräte ausreichen würden, kann das Modul die alternative Route vorschlagen, sodass der Nutzer die alternati ve Route lediglich bestätigen muss um zu bewirken, dass das Automatisierungssys tem des Fahrzeugs automatisch das Fahrzeug auf die alternative Route lenkt. Man che Analysemodule können ihr Analyseergebnis auch direkt an einzelne Fahrzeug komponenten 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 Be trieb 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 Analyse module 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 Daten bank 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 Flottenanaly- sesoftware 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 Daten austausch 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

P a t e n t a n s p r ü c h e
1. Militärisches Wasserfahrzeug (100), beinhaltend:
- mehrere Fahrzeugkomponenten (104-110), die jeweils ein oder mehre re Sensoren (112-120) beinhalten, wobei zumindest einige der Fahr zeugkomponenten zu einem Waffensystem (102), einer Antriebsein heit (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 per sistent und geschützt gespeichert sind; und
- ein elektronisches Automatisierungssystem (124), wobei das Automa tisierungssystem ausgebildet ist zur automatischen und/oder semi automatischen Steuerung von zumindest einer der Fahrzeugkompo nenten 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 er folgt.
2. Das militärische Wasserfahrzeug nach Anspruch 1, wobei das Wasserfahr zeug umfasst:
- mehrere zu einem Rechnerverbund (126) miteinander vernetze Com puter (202-208), die im Verbund als Flost so Zusammenarbeiten, dass zumindest eine Instanz der Datenbank bereitgestellt wird; und
- eine Containerverwaltungssoftware, wobei die Container verwaltungssoftware 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 Contai ner voneinander isoliert sind.
3. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche, ferner umfassend:
- ein oder mehrere Analysemodule (260-268), die jeweils dazu ausge bildet sind, eine Analyse von zumindest einem Teil der in der Daten bank (122) gespeicherten Messwerte auszuführen.
4. Das militärische Wasserfahrzeug nach Anspruch 3,
- wobei das Automatisierungssystem (124) einerseits und die ein oder mehreren Analysemodule (260-268) andererseits voneinander opera tiv entkoppelt sind; und/oder
- wobei sowohl das Automatisierungssystem als auch die ein oder meh reren Analysemodule dazu ausgebildet sind, ihre jeweiligen Steue- rungs- oder Analyse-Funktionen ohne Nutzung einer Internetverbin dung auszuführen.
5. Das militärische Wasserfahrzeug nach Anspruch 4, wobei die operative Ent kopplung 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 Au tomatisierungssystem 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 unter schiedlichen Computern (202-208; 290).
6. Das militärische Wasserfahrzeug nach einem der Ansprüche 3 bis 5, wobei de mehreren Analysemodule in mehreren unterschiedlichen Containern (212-230) und damit isoliert voneinander ausgeführt werden.
7. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 6, wobei in jedem der Container (212-230) maximal eine Instanz von maximal einem Ana lysemodul (260-268) ausgeführt wird.
8. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 7, wobei die Containerverwaltungssoftware (256) dazu konfiguriert ist, die Erzeugung von Containern (212-230) und die Instanziierung und das Beenden von Analyse modulen (260-268) so zu orchestrieren, dass:
- bei Ausfall oder Unerreichbarkeit eines der Computer (202-208) auto matisch auf einem anderen der Computer die Container und die Ana lysemodule gestartet werden, die durch den Ausfall oder die Uner reichbarkeit des einen Computers nicht mehr vorhanden oder erreich bar 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 ge hosteten 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 Analysemo dulinstanz auf diesen Computer zu migrieren; und/oder
- bei Überschreiten einer vordefinierten maximalen Rechenlast eines der Computer automatisch zumindest einen auf diesem Computer ge hosteten Container samt der darin laufende Analysemodulinstanz zu identifizieren, eine Kopie dieses identifizierten Containers samt darin laufenden Analysemodul auf mindestens einem weiteren der Compu ter 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 Com puter gehosteten Container samt der darin laufende Analysemodu linstanz zu identifizieren eine Kopie dieses identifizierten Containers samt darin laufenden Analysemodul auf diesen einen Computer zu in stanziieren; und Analysen unter Einbeziehung zumindest der Analy semodulinstanz in dem identifizierten Container und der weiteren in stanziierten Analysemodulinstanz parallel auszuführen.
9. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche 3 bis 8, wobei zumindest einigen der Analysemodule jeweils ein Teil der Daten der Da tenbank 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 zugewie sen ist.
10. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche 3 bis 9, 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 mehre ren Sensoren dieser einen Fahrzeugkomponente, der sie zugewiesen sind, er fasst werden, direkt oder indirekt über die Datenbank zu empfangen, zu analy sieren und das Ergebnis der Analyse auszugeben.
11. Das militärische Wasserfahrzeug nach Anspruch 10, wobei zumindest eines der mehreren Analysemodule, die einer der Fahrzeugkomponenten zugewie sen 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äch lich für einen kritischen Zustand der einen Fahrzeugkomponente sind; und/oder
- eine Berechnung einer Flandlungsempfehlung an einen Menschen in Bezug auf die eine Fahrzeugkomponente; und/oder
- eine Berechnung eines Steuerbefehls an die eine Fahrzeugkomponen te zur automatischen Durchführung des Steuerbefehls.
12. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche 3 bis 11 ,
- 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 Fahrzeugkom ponente zugeordnet ist und einen zu diesem kryptographischen Ver schlüsselungsschlüssel korrespondierenden Entschlüsselungsschlüs sel (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 Ana lysemodul zu übermitteln;
- wobei das zumindest eine Analysemodul dazu konfiguriert ist, die zu mindest einigen Messwerte mit dem Entschlüsselungsschlüssel zu entschlüsseln und die entschlüsselten Daten zu analysieren.
13. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche 3 bis 12, - wobei die Sensoren von zumindest einer der Fahrzeugkomponenten einen Signierschlüssel beinhalten;
- wobei eines der Analysemodule der zumindest einen Fahrzeugkom ponente zugeordnet ist und einen zu diesem Signierschlüssel korres pondierenden 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 ei nen Fahrzeugkomponente zugewiesene Analysemodul zu übermitteln;
- wobei das zumindest eine Analysemodul dazu konfiguriert ist, die zu mindest einigen Messwerte mit dem Signaturprüfschlüssel zu prüfen und die signierten Daten nur dann zu analysieren, wenn die Signatur prüfung ergibt, dass die Signatur valide ist.
14. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche 3 bis 13, wobei ein oder mehrere der Analysemodule jeweils dazu konfiguriert sind, ihr Ergebnis der Analyse an einen Nutzer und/oder an das Analysesystem auszu geben (404) und/oder in der Datenbank zu speichern.
15. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche 3 bis 14, 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 ei ner Fahrzeugkomponente; und/oder
- dem automatischen Identifizieren von ein oder mehreren Umgebungs- Parametern und/oder Fahrzeugkomponenten-Parametern, die ursäch- lieh 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 Fahrzeugkompo nenten zur automatischen Durchführung des Steuerbefehls.
16. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche 3 bis 15,
- wobei eine der Fahrzeugkomponenten eine Ruderanlage mit einer Steuerein heit, ein oder mehreren steuerbordseitigen und ein oder mehreren backbord seitigen 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, insbesonde re 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: ak tuelle 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 bein halten, die zur Erfassung von Umgebungs-Parameterwerten ausgebildet sind, wobei die Umgebungs-Parameter zwei oder mehr der folgenden Messparame terwerte umfassen: Wassertiefe, Seegang, Schiffsgeschwindigkeit;
- wobei eines der Analysemodule ein Analysemodul für die verbesserte Steue rung 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 Um gebungs-Parameterwerten zu erkennen und/oder um die Koordination der Ru der der Ruderanlage zu verbessern.
17. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche 3 bis 16,
- wobei eine der Fahrzeugkomponenten zumindest einen Sensor zur Erfassung von Schwingungen, insbesondere Vibrationen, dieser einen Fahrzeugkompo nente beinhaltet, wobei die eine Fahrzeugkomponente insbesondere eine Ra daranlage 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ünfti gen 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 Fahrzeugkompo nente insbesondere eine Ruderanlage ist.
18. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche 3 bis 17, wobei einer der Sensoren die Temperatur des das Wasserfahrzeug umgebe nen Wassers misst und in der Datenbank speichert, wobei eines der Analyse module dazu konfiguriert ist, den aktuellen oder künftigen Energieverbrauch und/oder den aktuellen oder künftigen Verschleißgrad einer Fahrzeugkompo nente in Abhängigkeit von der Temperatur des als Kühlwasser verwendeten Umgebungswassers zu berechnen.
19. Das militärische Wasserfahrzeug nach Anspruch 18, wobei das eine Analyse modul 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ünfti gen Energieverbrauch, die aktuell maximal mögliche Reichweite und/oder den aktuellen oder künftigen Verschleißgrad des Wasserfahrzeugs oder von Was serfahrzeugkomponenten zu berechnen.
20. Das militärische Wasserfahrzeug nach einem der vorigen Ansprüche, wobei Daten der Datenbank in den mehreren Computern verteilt und/oder redundant gespeichert sind.
21. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 20, wobei die Daten der Datenbank verteilt in verschiedenen Containern verschiedener Rechner gespeichert sind, wobei die Containerverwaltungssoftware dazu kon figuriert 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 üb rigen 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 ausge fallenen 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 gespei cherten Daten derart, dass der bisherige Grad der Redundanz der Da ten 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.
22. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 21, wobei zumindest einige der Rechner des Rechnernetzwerks jeweils in einem eigenen Sicherheitsbehälter enthalten sind, der feuerfest und/oder druckwellenrobust und/oder wasserdicht ist.
23. Das militärische Wasserfahrzeug nach einem der Ansprüche 2 bis 22, 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 Wasserfahr zeugs untergebracht sind, wobei die unterschiedlichen räumlichen Bereiche unterschiedliche Zimmer, unterschiedliche Decks, unterschiedliche durch was serdichte Schleusentore getrennte Kammern, Steuerbordseite und Backbord seite des Wasserfahrzeugs oder Bugseite und Heckseite des Wasserfahrzeu ges sind.
24. System (150) umfassend:
- mindestens zwei militärische Wasserfahrzeuge (100, 130, 132) gemäß einem der vorigen Ansprüche;
- ein Computersystem (134) mit: o einer Schnittstelle (136) zum sicheren Import des Inhalts der Datenbanken der mindestens zwei Wasserfahrzeuge; o eine Flottenanalysesoftware (138), wobei die Flottenanaly sesoftware dazu ausgebildet ist, die Messwerte der Datenban ken der mindestens zwei Wasserfahrzeugen zu analysieren, wobei die Flottenanalysesoftware dazu konfiguriert ist, automa tisch zu erkennen, ob die Messwerte unterschiedlicher Wasser fahrzuge von Fahrzeugkomponenten gleichen Typs erfasst wurden, wobei die Analyse umfasst: ■ eine Erkennung desjenigen der Wasserfahrzeuge, des sen 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 Fahrzeug- komponente in einem oder mehreren der Wasserfahr zeuge; 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 Fahrzeugkomponen- ten-Parametern, die ursächlich für einen kritischen Zu stand einer der Fahrzeugkomponenten in einem oder mehreren der Wasserfahrzeuge sind.
PCT/EP2021/050330 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren WO2021144206A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
BR112022014068A BR112022014068A2 (pt) 2020-01-16 2021-01-11 Embarcação militar com sensores
EP21700516.4A EP4090586A1 (de) 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren
KR1020227024734A KR20220109474A (ko) 2020-01-16 2021-01-11 센서들을 갖는 군용 선박

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020200471.4A DE102020200471B4 (de) 2020-01-16 2020-01-16 Militärisches Wasserfahrzeug mit Sensoren
DE102020200471.4 2020-01-16

Publications (1)

Publication Number Publication Date
WO2021144206A1 true WO2021144206A1 (de) 2021-07-22

Family

ID=74186672

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/050330 WO2021144206A1 (de) 2020-01-16 2021-01-11 Militärisches wasserfahrzeug mit sensoren

Country Status (5)

Country Link
EP (1) EP4090586A1 (de)
KR (1) KR20220109474A (de)
BR (1) BR112022014068A2 (de)
DE (1) DE102020200471B4 (de)
WO (1) WO2021144206A1 (de)

Families Citing this family (6)

* 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
DE102022209652A1 (de) 2022-09-14 2024-03-14 Thyssenkrupp Ag Signaturmanagementsystem
DE102022209654A1 (de) 2022-09-14 2024-03-14 Thyssenkrupp Ag Signaturmanagement unter Berücksichtigung von Satelliten

Citations (10)

* 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
DE102008057123A1 (de) * 2008-11-13 2010-05-20 Peter Friedrich Großkaliber- Artillerie auf kompakten Kampfschiffen und Schnellbooten
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
WO2019243932A1 (en) * 2018-06-21 2019-12-26 Kyrtatos Nikolaos Remote assessment of ship propeller fouling

Patent Citations (10)

* 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
DE102008057123A1 (de) * 2008-11-13 2010-05-20 Peter Friedrich Großkaliber- Artillerie auf kompakten Kampfschiffen und Schnellbooten
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
WO2019243932A1 (en) * 2018-06-21 2019-12-26 Kyrtatos Nikolaos Remote assessment of ship propeller fouling

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), pages 11, Retrieved from the Internet <URL:https://www.mlit.go.jp/common/001039009.pdf>

Also Published As

Publication number Publication date
BR112022014068A2 (pt) 2022-09-13
KR20220109474A (ko) 2022-08-04
EP4090586A1 (de) 2022-11-23
DE102020200471B4 (de) 2024-01-04
DE102020200471A1 (de) 2021-07-22

Similar Documents

Publication Publication Date Title
WO2021144206A1 (de) Militärisches wasserfahrzeug mit sensoren
Kavallieratos et al. Cyber-attacks against the autonomous ship
WO2006113450A1 (en) Decision support method and system
Kardakova et al. Cyber security on sea transport
Jacq et al. Cyber attacks real time detection: towards a cyber situational awareness for naval systems
Petković et al. Blockchain security of autonomous maritime transport
Pennanen et al. Integrated decision support system for increased passenger ship safety
Hamburger et al. It is not just hardware and software, anymore! Human systems integration in US submarines
KR20200082390A (ko) 블록체인 기반 선박 사고 데이터 임의 수정을 방지하기 위한 방법
US20120215734A1 (en) Maintenance figure of merit system and method for obtaining material condition of ships
Amrozowicz The quantitative risk of oil tanker groundings
Jorgensen Autonomous Vessels: ABS'Classification Perspective
Hall Utilizing a model-based systems engineering approach to develop a combat system product line
Boudehenn et al. A data extraction method for anomaly detection in naval systems
Ibrahim The impact of neurotechnology on maritime port security—hypothetical port
Hereau et al. Testing an underwater robot executing transect missions in mayotte
Reith et al. Operationalizing Cyber: Recommendations for Future Research
Crum et al. Certification challenges for autonomous flight control systems
Katsikas et al. Cybersecurity of the Unmanned Ship
Volkert et al. Development of modular mission packages providing focused warfighting capability for the littoral combat ship
Chauveau et al. Integration of Autonomous Heterogeneous Systems for Decision Making Autonomy in Naval Defence: A Position Paper
Mancini et al. Securing Autonomous and Unmanned Vehicles for Mission Assurance
Surya et al. Synergizing Aerospace Efficiency: Blockchain and AI Integration for Enhanced Security in Flight Data Management
Zhang Active fault-tolerant control systems: Integration of fault diagnosis and reconfigurable control
LAMPREIA et al. Cybersecurity Risk Assessment: the Ship Maintenance Databases’ Case Study

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21700516

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20227024734

Country of ref document: KR

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112022014068

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2021700516

Country of ref document: EP

Effective date: 20220816

ENP Entry into the national phase

Ref document number: 112022014068

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20220715