Loading [MathJax]/extensions/TeX/boldsymbol.js
An Intelligent Agent-Based Resilient Framework for Marine Vessel Mission Adaptations | IEEE Journals & Magazine | IEEE Xplore

An Intelligent Agent-Based Resilient Framework for Marine Vessel Mission Adaptations


Abstract:

Waterborne transport is very important for moving freight and passengers globally. To make this transport more efficient, vessel design must adapt to changing missions, r...Show More

Abstract:

Waterborne transport is very important for moving freight and passengers globally. To make this transport more efficient, vessel design must adapt to changing missions, regulations and the occurrence of malfunctions. This paper presents the design of an intelligent decision-support framework to assist marine engineers and vessel operators in updating the system and control architecture of marine vessels before and during a mission. The connection between the system architecture and control design perspectives is enabled using a semantics-based technique. To this end, the multi-level vessel control system is described by a semantic database, a knowledge graph used to connect the components automatically, and quantitative service criteria. Considering the system architecture, the optimal modification is deduced using modularity and complexity criteria, originating from the field of network theory. On the control side, an intelligent automation supervisor is designed to make offline and online decisions regarding the energy deficit to execute a new mission and the active automation configuration during operation. For offline decisions, system architecture modifications are requested by the vessel designers to cover the energy deficit. During operation, switching between hardware and virtual sensors as well as switching between energy management controllers is implemented to handle the effects of sensor faults. The framework is successfully applied to a case study of a tugboat used to adapt to missions with different power requirements, while simulation results are used to indicate its application in supporting the decisions of vessel designers and human vessel operators.
Page(s): 184 - 203
Date of Publication: 05 February 2025
Electronic ISSN: 2687-7813

Funding Agency:


CCBY - IEEE is not the copyright holder of this material. Please follow the instructions via https://creativecommons.org/licenses/by/4.0/ to obtain full-text articles and stipulations in the API documentation.
SECTION I.

Introduction

Waterborne transport is responsible for more than 90% of the global trade and the lives of more than a million passengers worldwide. Marine vessels can be considered as a system of systems, incorporating multiple subsystems and interconnections to remain operational. As such, they are often characterised by great modelling complexity, often higher than that of other applications (e.g., automotive applications [1]). During a typical life cycle of thirty to fifty years, multiple adaptation drivers can affect the design and operation of the vital vessel subsystems, such as the power and propulsion system, as shown in Figure 1. In particular, short-term adaptations would be required under the effects of malfunctions (e.g., sensor faults), including the online reconfiguration of the control architecture to sustain safe operation [2]. The management of malfunctions is crucial in modern transportation systems in a broader context (also for road, rail transport) for additional safety and security, and even more relevant with the cyber infrastructure continuously increasing. Medium-term adaptations concern the changes in the missions assigned to a specific vessel during its life-cycle, each associated with different operational environments and power requirements. A change in mission characteristics will, in most cases, subsequently lead to modifications in the vessel’s system design. This type of adaptations is also applicable to other sectors facing changes in power requirements/ mileage autonomy (e.g., electric trucks). Finally, long-term adaptations are attributed to changes in emission regulations by the International Maritime Organisation. More specifically, marine vessels are expected to apply a reduction of 40% in their carbon intensity by 2030 and a reduction of 70% and 50% in their carbon intensity and Green House Gas (GHG) emissions by 2050 respectively, compared to 2008 levels [3]. This has led to the emergence of alternative energy carriers (e.g., sodium borohydrides [4]) and exhaust treatment technologies as future viable alternatives for vessels. Intelligent tools for vessel emission monitoring have also started to emerge in recent years [5], [6]. However, up to this moment, there is no consensus on which alternative fuels, intelligent tools and system designs will prevail and for which vessels.

FIGURE 1. - Classification of marine vessel adaptation drivers based on their time scale.
FIGURE 1.

Classification of marine vessel adaptation drivers based on their time scale.

Considering the aforementioned uncertainty in the maritime industry regarding marine vessel adaptations, the need for resilient design methods becomes more prevalent. In this context, resilience is defined as “the ability of systems to prevent or adapt to changing conditions in order to maintain control over a system property” [7], where the properties considered are safety, mission-adaptability and sustainability. Moreover, the ongoing digitalisation of marine vessel systems, the use of online diagnosis [8] and reconfiguration strategies [2], pave the way for the development of intelligent tools for any operation of the vessel. These tools will allow vessels to proactively adjust their design to changing conditions, ensuring safe and resilient performance.

A. Literature Review

The focus of this work is how to efficiently change the system and control architecture of marine vessels for handling short-, medium- and long-term mission adaptations. Typically, the system architecture of marine vessels incorporates components from various manufacturers, using different communication protocols and naming conventions. Both at the initial design phase and during the vessel’s life cycle, it is the responsibility of the vessel designers (e.g., marine engineers) to select the components based on the specifications (e.g., emissions, produced power, attainable speed), manually draft their connection graph using expert knowledge and reiterate the design until the specifications are met. Reconfiguration of the system architecture is usually initiated by the operators (e.g., onboard crew, on-shore control centres) in case of maintenance, malfunctions or changes in mission specifications. As a result, considerable time and human labour are required at the initial design stage to keep the system architecture consistent with the regulatory framework. Moreover, similar to aerial vehicle applications [9], extensive efforts are required during the operation of the vessel for handling safety-critical adaptations due to changing weather conditions, malfunctions or differences in missions.

The selection of a modified system that complies with stricter regulations is based on several considerations, such as the new system’s efficiency, expenses (volume, weight, financial), maintainability and the required adjustments to the original system. Representing the system by a network provides tools to evaluate candidate system architectures using an endless list of graph-based metrics such as degree, shortest path and betweenness [10]. It is common knowledge amongst vessel designers that onboard power, fluid, and data distribution systems do not operate in isolation but have close relations with other systems, such as automatic control systems, and should be designed as interconnected systems. These relations and inter-dependencies strengthen with higher integration. Currently, the integration increases due to higher levels of autonomy and more complex and alternative power and energy systems. However, control systems are often ignored in this integrated multi-level system.

Control systems are, in most cases, designed for a specific iteration of the system architecture and take into consideration the chosen sizing [26], [27]. However, in case of system architecture adaptations, control needs to be redesigned from scratch to avoid problems such as inefficient use, or overloading of the vessel’s equipment, or even the inability to carry out new vessel missions with different power requirements. In most cases, marine vessels employ a multi-level control architecture with three levels of control (primary, secondary and tertiary) [28]. The secondary level consists of the energy management strategy where the reference signals for the primary level controllers are determined based on an optimisation problem. The objective functions in this case are related to the maximisation of the energy performance of the vessel [29], [30] or the minimisation of fuel consumption with the use of an Equivalent Consumption Minimisation Strategy (ECMS) [31]. However, the energy management strategy often becomes specific to a selected system architecture and size and is thus unfit for adapting to missions with different power requirements. To handle this issue, the authors of [32] consider swapping battery energy storage between stations on inland waterways. The voyage scheduling and energy management are both optimised in a joint optimisation problem. Another approach includes the design of multiple energy management strategies based on known iterations of the vessel system architecture to adapt to new missions and a digital supervisor installed to switch between these strategies during operation [33], [34]. So far in marine literature, the technological aspects regarding the implementation of the digital supervisor and the occurrence of anomalies such as sensor faults during operation have not been investigated.

Nowadays, an increasing number of intelligent tools are developed to ensure the safe and secure operation of marine vessels, optimise their subsystem architecture and reduce costs. The authors of [15], [16] describe the use of digital twin technology for fault diagnosis and accommodation of marine propulsion plants using neural networks. The proposed data-driven technique is built with a specific propulsion plant design and any alteration to its design will cause the need for retraining with updated data. In [17], a multi-head attention neural network approach is employed, to correlate data sequences to reflect the status variation of different machinery. As a result, faulty signal behaviours can be identified. The aforementioned papers do not consider the implementation aspects of these technologies. Moreover, the authors of [13] propose a co-simulation platform (coupling of simulators) that will enable fast and reliable testing and optimisation of vessel system and automation designs before construction, and that can also be used for training purposes of crews during the vessel’s life cycle. In this work though they do not consider the closed-loop operation of the individual machinery and their integration. The applicability of the method depends on the availability of the machinery models the manufacturers are willing to provide for the platform. In this platform [13], the occurrence of faults during the operational phase of the vessel is not explored as a change mechanism for the installed system configuration during operation. Another ship simulation platform is proposed in [14]. In this case, virtual reality tools (i.e., 3D models of the system architecture, environmental disturbances) are employed for the training of marine crews. However, the platform explores neither system architecture adaptations nor the control design. The authors in [18] on their end, employ an input/output description of the systems included in the vessel architecture and develop an algorithm based on constraint programming for the automatic generation of different system architectures. The impact of the controlled operation is not studied in this paper and no discussion is included on system architecture adaptations for different missions. Finally, in both [11], [12], the authors discuss the control design adaptation of marine vessels for different operational modes and power requirements using a bank of controllers and a power load estimator, respectively. However, the system architecture aspect of the design is not considered to be adaptable and the occurrence of vulnerabilities during operation, such as sensor faults, is not taken into consideration. The management of these vulnerabilities is crucial in modern transportation systems in a broader context (e.g., road, rail transport) for additional safety and security, and even more relevant with the cyber infrastructure continuously increasing. There exists no integrated mission-adaptive framework that includes both system architecture and control design perspectives of marine vessels.

B. Proposed Intelligent Agent-Based Resilient Framework

In this research work, we propose an intelligent framework to enable short-, medium- and long-term adaptations of marine vessels to a variety of missions with different characteristics. In Figure 2, an overview of this framework is presented. The main human actors are the system designers/ integrators (i.e., marine engineers) and the vessel operators (i.e., crew members, remote control centres). In order to support life cycle seamless adaptation decisions the designer is aware of the initial layout of the power and propulsion plant which translates into the semantic information of the system components, used to form the database {\mathcal {F}}_{p} , and the semantic information of the installed automation components, used to form the database {\mathcal {F}}_{A} . An automated algorithm to link the components included in the semantic database into knowledge graphs G_{p}^{(s)} and G is also developed and used to support both system architecture and automation design decisions. The term knowledge graph will hereby refer to graphs automatically constructed using the knowledge available in the semantic database. The semantic database proposed in the context of this research work is described in Section III. During the vessel’s life cycle, information of the mission characteristics is collected by an intelligent automation supervisor whose task is, in combination with the received plant feedback (e.g., diagnosis sets by monitoring agents, component availability), to make decisions on the secondary level controller to be used and the corrective actions to enforce in case of multiple sensor faults affecting the power and propulsion plant operation. Thus, the intelligent automation supervisor supports the decisions made by the operators either by indicating that the operation for a specific mission is not feasible with the available equipment or by counteracting vulnerabilities such as sensor faults during the vessel operation, in an effort to promote onboard safety. The decision vector of the intelligent supervisor and its mapping to the active configuration \mathcal {I} (output of the intelligent supervisor) will be further analyzed in Section V.

FIGURE 2. - Intelligent agent-based resilient framework for mission-adaptive marine power and propulsion plants.
FIGURE 2.

Intelligent agent-based resilient framework for mission-adaptive marine power and propulsion plants.

FIGURE 3. - Graph depiction of the relations between the set of inputs from the mission Definition 1 
$(\mathcal {U})$
, the vessel characteristics (features of interest 
$\mathcal {L}$
 and capabilities P), the extracted mission characteristics 
$\mathcal {Z}=\{S_{m},O_{e},V_{O_{m}},\nabla \}$
 and the power demand output 
$\mathcal {Y}=\{P_{D},\,P_{aux},\,P_{tot}\}$
. The notation 
$\mathcal {G}(\mathcal {I},\mathcal {O},E^{(\mathcal {I},\mathcal {O})})$
 is used to denote the directed sub-graph 
$\mathcal {G}$
 with a starting vertex belonging to the set 
$\mathcal {I}$
 and an end vertex belonging to the set 
$\mathcal {O}$
, with the edge 
$E^{(\mathcal {I},\mathcal {O})}$
 connecting them [22].
FIGURE 3.

Graph depiction of the relations between the set of inputs from the mission Definition 1 (\mathcal {U}) , the vessel characteristics (features of interest \mathcal {L} and capabilities P), the extracted mission characteristics \mathcal {Z}=\{S_{m},O_{e},V_{O_{m}},\nabla \} and the power demand output \mathcal {Y}=\{P_{D},\,P_{aux},\,P_{tot}\} . The notation \mathcal {G}(\mathcal {I},\mathcal {O},E^{(\mathcal {I},\mathcal {O})}) is used to denote the directed sub-graph \mathcal {G} with a starting vertex belonging to the set \mathcal {I} and an end vertex belonging to the set \mathcal {O} , with the edge E^{(\mathcal {I},\mathcal {O})} connecting them [22].

FIGURE 4. - (a) Typical hybrid power and propulsion plant architecture used in marine vessel applications. The hybrid characterisation denotes the use of both mechanical (internal combustion engine) and electric (induction motor) power for propulsion and the use of both AC (generators) and DC (batteries) components for power generation; (b) Representation of the hybrid power and propulsion plant shown in (a), using semantic knowledge 
${\mathcal {F}}_{p}$
 such as the one seen in Table 2 and the automated knowledge graph algorithm (Algorithm 1). The vertices V of the graph (system architecture components) are coloured based on the subsystem of this component while the edges E between vertices are also shown in multiple colours, each signifying the use of a different medium 
$\Upsilon $
.
FIGURE 4.

(a) Typical hybrid power and propulsion plant architecture used in marine vessel applications. The hybrid characterisation denotes the use of both mechanical (internal combustion engine) and electric (induction motor) power for propulsion and the use of both AC (generators) and DC (batteries) components for power generation; (b) Representation of the hybrid power and propulsion plant shown in (a), using semantic knowledge {\mathcal {F}}_{p} such as the one seen in Table 2 and the automated knowledge graph algorithm (Algorithm 1). The vertices V of the graph (system architecture components) are coloured based on the subsystem of this component while the edges E between vertices are also shown in multiple colours, each signifying the use of a different medium \Upsilon .

In case the operation is declared infeasible by the intelligent automation supervisor, the operators will proceed to request a design update from the designer as a response to updated operational requirements (e.g., operation in harsh seas). Considering the current situation in emission regulations, technological developments, stock of components and financial targets, the designer decides on certain candidate system architecture adaptations to satisfy the new operational demand, such as the ones already shown in Figure 5. Another intelligent function, denoted as the intelligent system architecture decision support module, is then designed to assist the designer in choosing the optimal system architecture alteration, based on the semantic information stored in the system databases {\mathcal {F}}_{p,i} and a ranking of the resulting graphs G_{p,i},\;i\in \{0,\ldots , N_{t}\} , where N_{t} corresponds to the number of candidate system architecture considerations (N_{t}=3) , using graph complexity and modularity-related network metrics. The decision of the intelligent system architecture decision support module, denoted by \sigma _{d} is the “systems” that will be installed to handle the new mission and its mapping to the selected systems database {\mathcal {F}}_{p}^{(s)} (output of the life cycle decision support module) is elaborated in Section IV. The complete semantic database \mathcal {F} to be used in the power and propulsion plant operation is then formed and provided as input together with the complete knowledge graph G to the intelligent automation supervisor.

FIGURE 5. - Candidate system architecture alteration choices as a response to higher energy demands of the new mission 2 with (a) suggesting the addition of battery stack to the energy storage, (b) proposing the conversion to methanol and addition of Solid Oxide Fuel Cells (SOFC) to energy storage and (c) combining the conversion to methanol and addition of both battery stacks and fuel cells.
FIGURE 5.

Candidate system architecture alteration choices as a response to higher energy demands of the new mission 2 with (a) suggesting the addition of battery stack to the energy storage, (b) proposing the conversion to methanol and addition of Solid Oxide Fuel Cells (SOFC) to energy storage and (c) combining the conversion to methanol and addition of both battery stacks and fuel cells.

C. Contributions and Outline

Compared to previous work of the authors [2], [22], this paper combines both the system architecture and control design aspects of marine vessels while elaborating on the implementation aspects that will enable the use of the proposed intelligent framework in real applications. Moreover, compared to [25], we have developed a new semantic description of marine multi-level control architectures and the information flow from the control to the system architecture design perspectives is explored. The switching logic originally discussed for sensor faults in [2] and applied in [25] is adapted for use in energy storage and further enhanced by switching decisions regarding the unavailability of knowledge graph components. Finally, previous work of the authors [23], [24] addresses modularity as a robustness aspect but does not take design complexity into account. The contributions of this work with respect to the state of the art in marine literature can be observed in Table 1.

TABLE 1 Classification of Papers on Intelligent Design of Marine Vessels and Comparison With the Research Work Presented in This Paper. Research Work of the Authors is Highlighted in Bold
Table 1- Classification of Papers on Intelligent Design of Marine Vessels and Comparison With the Research Work Presented in This Paper. Research Work of the Authors is Highlighted in Bold

The main contribution of this paper is the development of an intelligent agent-based resilient framework to assist the humans-in-the-loop in the decision-making regarding vessel design adaptations. In particular, the proposed framework combines medium- and long-term decisions related to system architecture adaptations (Section IV) and the feasibility of executing the mission (Section V), alongside short-term control switching decisions during online operation (Section V). To ensure the vessels’ resilience against mission adaptations (Section II), synergy is promoted between the system architecture and control system design perspectives. To this end, the semantic database, originally introduced by [25] is expanded for use in marine multi-level control schemes under operational safety considerations (Section III) and used to link both design perspectives. In comparison to the state-of-the-art methods (Table 1), novel performance metrics originating from the field of network theory and related to both knowledge graph modularity and complexity (Section IV) are considered in this paper for system architecture adaptation decisions. Similar network metrics could also be beneficial in the case of inter-vessel and vessel-to-shore networks as a means of evaluation of the system architecture. From the control perspective, the consideration of a mission adaptable system architecture coupled with a modular control system (Section V) allows for enhanced flexibility regarding the re-purposing of the vessel in a variety of operations. The incorporation of quantitative alongside qualitative models enables the consideration of the operational aspects and malfunctions (see the Appendix). More specifically, this paper considers both sensor faults and graph unavailability events (Section V), occurring during operation, further advocating for enhanced resilience. The consideration of the power and propulsion plant as a case study (Section VI) has a great impact on the sustainability of future marine vessels, and is followed by concluding remarks in Section VII.

SECTION II.

Correlation Between the Mission, Power Profile and Design Adaptations

In most marine vessel types found in practice the time scale needed for system component adaptations, and by association automation adaptations, is considered large. For that reason, most relevant papers in literature only consider a specific system layout when designing the automation systems. However, there are types of marine vessels for which the system design needs to be frequently adjusted to accommodate different missions (e.g., dredgers, patrol vessels). Let us define X as the cargo/passengers/vessel in need of transportation, and A,\,B,\,C,\,D \in \mathbb {R}^{2} as the coordinates (i.e., [latitude,longitude]) of the locations visited. In this work, we define the mission as [22]:

Definition 1 (Mission):

Transport X from A to B (optionally via C, D, etc.), leaving at t_{0} (time and date), arriving at t_{end} (time and date).

The correlation between the mission, the power profile and the required adaptations is depicted in Figure 3. Based on Definition 1, the input vector is expressed as \mathcal {U}=\{X,\,A,\,B,\,t_{0},\,t_{end}\} . Using this vector, the type of vessel X_{v} (e.g., tugboat, Ro/Ro ferry) and the vessel characteristics such as the proportionality between the vessel speed and required power a, propeller diameter D, fouling f_{h} , torque coefficient K_{Q} , thrust coefficient K_{T} , and propulsive efficiency \eta _{D} can be derived. We refer to these characteristics as the features of interest \mathcal {L}=\{X_{v},\,a,\,D,\,f_{h},\,K_{Q},\,K_{T},\,\eta _{D}\} . The operational modes O_{m} of the vessel characterized by the set \mathcal {L} and selected to meet the inputs from the mission \mathcal {U} comprise the capabilities of the vessel \mathcal {P}=\{O_{m,1},\,O_{m,2},\,\ldots , \,O_{m,end}\} where, for each O_{m,i} , the indices i=1,\ldots , end correspond to various time points t_{i}\in [t_{0},t_{end}] during the vessel’s mission. Moreover, based on the input vector \mathcal {U} and the capabilities of the vessel \mathcal {P} , the set of mission parameters \mathcal {Z}=\{S_{m},\,O_{e},\,V_{0_{m}},\,\nabla \} can be derived where S_{m} denotes the travel route, O_{e} are the parameters of the operational environment (waves w_{s} , currents c_{s} , wind w_{w} , ambient temperature T_{a} , water depth h, and waterway width w_{w} ), V_{0_{m}} is the speed of the vessel during each operational mode O_{m} , and \nabla signifies the displacement of the vessel. Finally, the information from the features of interest \mathcal {L} and the mission parameters \mathcal {Z} is used to predict the power requirements of the vessel in propulsion (P_{D}) , auxiliary (P_{aux}) and total power (P_{tot}) , also denoted as the output vector \mathcal {Y} . The above defined sets and their relations are depicted in Figure 3 while the resulting equations of the power profile (P_{D} , P_{aux} and P_{tot} ) are expressed as [22]:\begin{align*} P_{aux}(t)=& P_{aux,c}\left ({{X_{v}}}\right ) + \Delta P_{aux}\left ({{O_{m},T_{a},X_{v}}}\right ), \tag {1}\\ P_{D}(t)=& \frac {f\left ({{s_{s},w_{s},c_{s},h_{i},w_{w},f_{h},{\nabla }}}\right ) \cdot c_{0} \cdot {V_{O_{M}}}^{a}}{\eta _{D}} \\& {}+|{F_{tow}}|^{\frac {3}{2}} \frac {2\pi K_{Q}}{\sqrt {\rho } D K_{T}^{\frac {3}{2}}}, \tag {2}\end{align*} View SourceRight-click on figure for MathML and additional features.with F_{tow} denoting the towing force consideration in certain vessel types such as tugboats. The total power profile is then expressed as:\begin{equation*} P_{tot}(t)=P_{D}(t)+P_{aux}(t), \tag {3}\end{equation*} View SourceRight-click on figure for MathML and additional features.Between two different missions (e.g., Mission 1, Mission 2), the difference in the required propulsion (\Delta P_{D}) , auxiliary (\Delta P_{aux}) and total power (\Delta P_{tot}) can be computed. Decisions can then be made on the necessary plant adaptations to adapt a specific vessel from Mission 1 to Mission 2. Nonetheless, considering the various component choices offered by the industry (e.g., batteries, fuel-cells, alternative fuels) to adapt to greater power requirements while making the vessel operation more sustainable, the optimality of the adaptation decision should be examined. In this paper, system architectures such as the one shown in Figure 4(a) for a marine power and propulsion plant are considered. The propulsion plant is composed of an internal combustion engine and an electric motor connected in parallel to the same shaft line via a gearbox. The gearbox is then used to drive the propeller shaft, equipped with a fixed-pitch propeller (FPP). The power for the electric motor and auxiliary machinery (e.g., Heating, Ventilation and Air Conditioning system, ballast water treatment system) is provided by the main bus bar after some frequency converters. The main bus bar is fed with the AC power delivered by two generator sets and the DC power provided by an available battery stack, through a DC/AC converter. Taking into account the different fuel choices, three candidate system architecture adaptations from the initial design layout seen in Figure 4(a) are considered, and the respective system architectures are illustrated in Figure 5(a)-​5(c) [35]. Candidate system architecture 1 (Figure 5(a)) assumes that more battery energy storage will be added. Candidate system architecture 2 (Figure 5(b)) suggests a change from fossil fuels to methanol and the addition of fuel cells aside the available battery storage. Finally, candidate system architecture 3 (Figure 5(c)) serves as a combination of the previous two candidate system architectures.

The objective of this research work is to develop an intelligent framework that integrates the system architecture and control design perspectives to support seamless adaptation decisions made by designers and operators during the vessel’s life cycle, in response to the change of operation from Mission 1 to Mission 2. From the system architecture perspective, a decision framework will be proposed based on quantitative graph-based metrics to decide on the optimal candidate system architecture (1,2 or 3) to use for Mission 2. The use of an intelligent automation supervisor will also be introduced to enable modularity in the vessel control system in line with the updated power requirements. In addition, the intelligent supervisor will be designed to handle the occurrence of multiple sensor faults and graph unavailability events that can affect the operation of marine vessels.

SECTION III.

Qualitative Modelling of Multi-Level Vessel Operation

In literature, many models are available describing the dynamics of the various subsystems encountered in marine power and propulsion systems [36], [37]. These models are often characterised by high nonlinearity and complexity with their details being more of value in the operational stage (e.g., control, emissions prediction, fault diagnosis) rather than the vessel design phase. For this reason, the basis of the integrated life cycle decision and automation support system presented in Figure 2, which enables the use of intelligent functions, is a qualitative modelling technique based on semantics. In previous work [25], a semantic database of vessel components was introduced. The semantic database is composed of the following parts; (a) the semantic database \mathcal {F} where the semantic information about the system components is stored; (b) the knowledge graph G, a tool that helps visualize the connections between the different hardware and cyber components based on their semantic information, and; (c) multiple Quality of Service (QoS) criteria that are used for system architecture and control design assessment purposes.

The semantic database is enriched by semantic information provided either by the designer (e.g., the propeller needs torque from the power and propulsion system to produce thrust for the vessel) or by system manufacturers (e.g., fuel engine operational maps). Using the semantic information of the vessel components (knowledge provided by experts/designers and manufacturers), an automated algorithm is proposed to construct a knowledge graph (G) . Finally, the Quality of Service (QoS) criteria are mostly set by the operators and can include new mission descriptions, power profiles, combinator curves etc. (quantitative data).

A. Semantic Database (\mathcal {F})

In this research work, multi-level control system architectures are considered, such as those often encountered in marine power and propulsion plants. As can be seen in Figure 6. In order to handle design uncertainty regarding both system architecture and control aspects, we propose a qualitative modelling technique based on semantics. To this end, the physical and cyber power and propulsion plant components are described as follows:

FIGURE 6. - Semantic representation of a typical multi-level control system with two “systems” comprising the plant in the semantic database 
$\mathcal {F}$
. The database is composed of two parts, the system architecture modules 
${\mathcal {F}}_{p}$
 and the automation modules 
${\mathcal {F}}_{A}$
.
FIGURE 6.

Semantic representation of a typical multi-level control system with two “systems” comprising the plant in the semantic database \mathcal {F} . The database is composed of two parts, the system architecture modules {\mathcal {F}}_{p} and the automation modules {\mathcal {F}}_{A} .

“System”: Systems \Sigma ^{(I)},\,I=1,\ldots , n_{I} each have necessary input and output mediums. Therefore, system components are added to the database including input and output information for the specific medium (e.g., water, air, etc.). For instance, the fuel pump(s), electric motors, internal combustion engines, batteries, and propellers found inside marine vessels can be considered as system components.

“Controller”: In a multi-level control scheme (such as those frequently encountered in marine vessels), multiple “Controllers” at different levels are needed to coordinate the system operation. A “Controller” at the level l,\,l=1,\ldots , L of the control system can be generally expressed as u(k)=f_{c}(y(k),ref(k),\hat {x}(k),\hat {g}_{p}(k);\zeta _{c},\,l) where u(k) is the control decision signal, f_{c} describes the algorithm for deciding on which action to take next, y(k) represents the plant feedback, ref(k) is the reference trajectory of the system state, \hat {x}(k) is the estimated system state, \hat {g}_{p}(k) denotes the estimation of possible unknown system dynamics, and \zeta _{c} are parameters used by the controller implementation (e.g., controller gains).

“Monitoring agent”: The monitoring agent \mathcal {M}^{(I)} is used to oversee the health of sensors \mathcal {S}^{(I)} belonging to system \Sigma ^{(I)},\,I=1,\ldots , n_{I} . Due to the complexity associated with marine systems, each “monitoring agent” is typically composed of one or more “monitoring modules” M^{(I,q)},\,q=1,\ldots , q_{I} [38]. The decision vector resulting from this comparison is then compared to certain binary sensor fault signature matrices at two levels of isolation, as already described in [39]. The result of the diagnosis is a mapping R^{(I)} \rightarrow \mathcal {S}^{(I)}_{F} with R^{(I)} denoting the set of residuals and \mathcal {S}^{(I)}_{F} denoting the faulty sensor set, as a result of the diagnosis process.

“Virtual sensor”: Each “virtual sensor” instance leverages the analytical redundancy of the system in order to create virtual and fault-free measurements and is part of a “monitoring agent”. It is activated after the detection and isolation of sensor faults by the respective “monitoring module”, thus increasing computational effectiveness. A “virtual sensor” is described by the equation \hat {x}^{(I)}(k)=f^{(I)}_{v}(\hat {x}^{(I)}[k-1], y^{(I)}[k], u^{(I)}[k],\hat {x}^{(I)}[k];\zeta _{s}^{(I)},\,\mathcal {S}^{(I)}_{F}) , where \zeta _{s}^{(I)} denotes the design parameters of the virtual sensor. In previous work [2], three types of “virtual sensors” have been defined for Differential-Algebraic systems and may be used under this module label; dynamic virtual sensors, static virtual sensors, and Set Inversion via Interval Analysis (SIVIA) [40] “virtual sensors”.

The previously described “system” semantic modules are denoted as {\mathcal {F}}_{p} . We then express the “automation” semantic database, denoted by {\mathcal {F}}_{A} , as:\begin{equation*} {\mathcal {F}}_{A}={\mathcal {F}}_{a}\cup {\mathcal {F}}_{c}\cup {\mathcal {F}}_{s}\cup {\mathcal {F}}_{e}\cup {\mathcal {F}}_{y}\cup {\mathcal {F}}_{u}\cup {\mathcal {F}}_{m}\,\cup {\mathcal {F}}_{v}, \tag {4}\end{equation*} View SourceRight-click on figure for MathML and additional features.where {\mathcal {F}}_{a},\,{\mathcal {F}}_{c},\,{\mathcal {F}}_{s},\,{\mathcal {F}}_{e},\,{\mathcal {F}}_{y},\,{\mathcal {F}}_{u} denote the set of “actuators”, “controllers”, “sensors”, “state-estimators”, “pre-control functions” and “post-control functions” respectively. The novelty of the present paper regarding the semantic module database resides in a richer description of the “system” and its associated set {\mathcal {F}}_{p} and the addition of module sets for “monitoring agents” and “virtual sensors” denoted as {\mathcal {F}}_{m},\,{\mathcal {F}}_{v} , respectively.

In the context of one or more candidate system architectures i,\;i=\{0,\ldots , N_{t}\} , multiple “system” databases {\mathcal {F}}_{p,i} are formed each corresponding to a different candidate system architecture. Finally, the complete semantic database is defined as:\begin{equation*} \mathcal {F}={\mathcal {F}}_{p}^{(s)}\cup {\mathcal {F}}_{A}, \tag {5}\end{equation*} View SourceRight-click on figure for MathML and additional features.where {\mathcal {F}}_{p}^{(s)} denotes the selected system architecture semantic description (e.g., {\mathcal {F}}_{p,1} , {\mathcal {F}}_{p,2} or {\mathcal {F}}_{p,3} ). The selection of system architecture {\mathcal {F}}_{p}^{(s)} for the power and propulsion system is based on complexity and modularity measures of the associated knowledge graph; the relevant methodology will be presented in Section IV.

For instance, the power and propulsion plant system architecture, such as the one shown in Figure 4(a), can be semantically described using the above description and expert knowledge on the additional components needed for operation, such as coolers, fuel tanks, etc. An excerpt of this information used to construct the system database {\mathcal {F}}_{p} is shown in Table 2. Similar representation techniques are also considered from the control design perspective.

TABLE 2 Excerpt of Semantic Information for the Hybrid Power and Propulsion Plant Shown in Figure 4(a)
Table 2- Excerpt of Semantic Information for the Hybrid Power and Propulsion Plant Shown in Figure 4(a)

B. Knowledge Graph (G)

The knowledge graph of the plant is a graph representation of the plant’s components (e.g., systems, controllers, sensors) formed using the available semantic knowledge specified by experts, such as designers and manufacturers in the semantic database \mathcal {F} . In particular, the connections between the different types of components are based on matching semantic inputs to semantic outputs. This process can take place both in the system architecture design phase of the plant, where information about the systems is solely prescribed, and in the control design phase where the semantic information of the physical and control components is also relevant. The knowledge graph G serves as a map for identifying the dependencies of each component and for visualising the complexity and modularity of the design layout.

In this research work, we develop an algorithm (see Algorithm 1) to generate the knowledge graph G based on the semantic information about the plant, included in the semantic database \mathcal {F} . The resulting knowledge graph is expressed as G\{V,E,\Upsilon \} where: (1) vertices (V) are the entries of the semantic database (e.g., electric motor, internal combustion engine, shaft speed sensor), (2) edges (E) express the connections between vertices (e.g., the induction motor is connected to the DC/AC converter) and (3) mediums (\Upsilon ) specify the information carried by the connection (e.g., AC voltage is used as the medium between the induction motor and the DC/AC converter).

Algorithm 1 Automated Function for the Generation of Knowledge Graphs Using Semantic Information

Input:

{\mathcal {F}}_{p,0}, \cdots , {\mathcal {F}}_{p,N_{t}}, {\mathcal {F}}_{A}-{\mathcal {F}}_{m}~\triangleright Databases

Output:

G~\triangleright Knowledge Graph

1:

for i=0:N_{t} do

2:

V \gets {\mathcal {F}}_{p,i} ; E \gets \emptyset ; \Upsilon \gets \emptyset \triangleright System architecture

3:

for v_{1} in V do\triangleright Physical plant connections

4:

for v_{2} in V do

5:

y \gets v_{2}.output \cap v_{1}.input~\triangleright y: medium

6:

if y\neq \emptyset then\triangleright Components can be connected

7:

E \gets E\cup \{v_{2},v_{1}\}

8:

\Upsilon \gets \Upsilon \cup \{y\}

9:

end if

10:

end for

11:

end for

12:

G_{p,i} \gets \{V, E, \Upsilon \} \triangleright Physical plant knowledge graph

13:

end for

14:

Intelligent system architecture decision support module: {\mathcal {F}}_{p,i}\mapsto {\mathcal {F}}_{p}^{(s)} by assessing G_{p,i},\;i=1,\ldots ,N_{t} \triangleright Section IV

15:

V \gets {\mathcal {F}}_{p}^{(s)}\cup \{{\mathcal {F}}_{A}-{\mathcal {F}}_{m}\}; E \gets \emptyset ; \Upsilon \gets \emptyset \triangleright Control

16:

Execute lines 3-11

17:

s_{g} \gets {\mathcal {F}}_{s}\{sensor\_groups\} \triangleright Sensor grouping information

18:

for i=1:length(s_{g}) do\triangleright Monitoring agents generation

19:

V \gets V\cup \{M\_i\}

20:

S \gets \{s \in {\mathcal {F}}_{s}\cap s_{g}[i]\}~\triangleright Connect sensors

21:

C \gets \{c \in {\mathcal {F}}_{c} \cap S.edges\} \triangleright Connect controllers

22:

E \gets E\cup \{\{S,M\_i\},\,\,\,\{C,M\_i\}\} \triangleright Update edges

23:

\Upsilon \gets \Upsilon \cup \{S.output,\,\,C.output\} \triangleright Update mediums

24:

E \gets E\cup \{M\_i,C\} \triangleright Update edges

25:

\Upsilon \gets \Upsilon \cup \{M\_i.output\} \triangleright Update mediums

26:

end for

27:

{\mathcal {F}}_{m} \gets \{M_{1},\ldots ,M_{s_{g}}\}

28:

G \gets \{V, E, \Upsilon \}~\triangleright Multi-level system and automation knowledge graph (cyber-physical)

In the system architecture design phase, the knowledge graph generation algorithm (Algorithm 1) begins with a list of “systems” that are considered by the designer for each candidate system architecture adaptation required to support new missions. The algorithm then starts, for instance, from a propeller (see vertex v_{1} in line 3) and connects the system components (vertices v_{2} ) that are necessary for the propeller to be operational in lines 4-11. When multiple systems have the same input or output, graphs are duplicated. The aforementioned lines of the Algorithm 1 are run for each different system architecture consideration (e.g., initial and candidate system architectures seen in Figure 4(a, 5), resulting in the knowledge graph for each system architecture G_{p,i},\;i=\{0,\ldots , N_{t}\} in line 12. For instance, the knowledge graph corresponding to the initial system architecture 4(a), denoted as G_{p,0} , is shown in Figure 4(b).

A decision is made on which system architecture to use based on the resulting knowledge graphs, as detailed in Section IV. Thus, the set {\mathcal {F}}_{p}^{(s)} is obtained (line 14). To make the chosen configuration operational, the addition of automation components is required. In the control design phase, the algorithm starts by connecting the automation components (excluding “monitoring agents”), as shown in lines 15-16. Moreover, the information about the grouping of hardware sensors is used to generate the “monitoring agents” (belonging to set {\mathcal {F}}_{m} ) and their connections in lines 17-27. A “monitoring agent” requires the output of relevant hardware sensors and controller(s) to provide decisions on the occurrence of faults. Moreover, its output (fault decision) can be used as input to the controller(s) it is associated with in a fault-tolerant control scheme [2]. Finally, the complete cyber-physical knowledge graph is generated based on the prescribed vertices, edges, and mediums, as shown in line 28.

C. Quality of Service (QoS) Criteria

The Quality of Service (QoS) criteria are quantitative criteria employed in addition to the qualitative models described in the semantic database \mathcal {F} and the knowledge graph G, in order to enable the use of the intelligent system architecture and control design framework. On the one hand, from the perspective of system architecture, criteria based on graph theory are used to quantify the complexity and modularity measures of the extracted knowledge graphs from a set of candidate system architectures. On the other hand, quantified power profiles based on the description of different missions (see Section II) are used on the control side. Moreover, the components belonging to the hardware ({\mathcal {F}}_{s}) and the virtual ({\mathcal {F}}_{v}) sensor set are to be used interchangeably by the system when one or more hardware sensors fail during operation. Considering control system performance, switching to the sensor with the minimum reference tracking error is preferable. However, certain types of virtual sensors require a long time for convergence, so choosing a sensor with a higher convergence rate but moderate reference tracking error to avoid danger is also a reasonable option. The time to switch is also taken into consideration as multiple consecutive switches may compromise control stability. The aforementioned criteria have already been explained in detail in [2].

SECTION IV.

Intelligent System Architecture Decision Support Module

This section will address the uncertainty associated with future system adaptation decisions due to the high availability of multiple heterogeneous components. The iterations of the system architecture (see Fig. 4(a), 5), represented by their knowledge graphs G_{p,i} (Section III), are compared based on the following two properties: complexity and modularity. The goal of reducing a system’s physical and functional complexity is to increase the system’s availability, reduce development and operational expenses, and enhance performance [41]. These effects are generally desirable and in line with the design requirements of power and propulsion plant systems (see Section II). Vessels can generally be regarded as complex systems [42]. Such systems with high complexity are more adaptive to different missions if they also possess a modular nature [43]. This adaptability is vital for vessels in the ongoing energy transition. Both complexity and modularity are system properties that can be evaluated based on the knowledge graphs’ network architecture representation.

A. Knowledge Graph Complexity

Quantitatively determining the complexity of the knowledge graph corresponding to each system architecture iteration is essential for reducing the complexity of onboard power and propulsion systems. A complex network can be a large network (a high number of vertices), having a high number of cycles or clustering coefficient [44], many different subgraphs [45], emergent properties from a functional perspective [46] or a high entropy [47]. The degree distribution can be used to categorize different network types. This distribution indicates the number of vertices with a given number of edges. Like most real-life networks, power and control systems onboard vessels often have a degree distribution on the bandwidth between the structure of an Erdös-Rényi random network [48] all edges have a fixed and independent probability of being present) and a scale-free network. However, we can assume that a supplier-user structured network has hub vertices and is thus closer to a power-law distribution1 [49]. Algorithm 2 shows the calculation of Shannon entropy H_{i} as a proxy for the complexity of undirected unweighted networks, corresponding to the knowledge graphs G_{p,i}\;i\in \{0,\ldots , N_{t}\} [50].

Algorithm 2 Assessment of Knowledge Graph Complexity Using the Global Shannon Entropy Metric [50]

Input:

G_{p,0},\ldots ,G_{p,N_{t}}~\triangleright Knowledge Graphs

Output:

H_{i}~\triangleright Global Shannon Entropy for each knowledge graph

1:

for i=0:N_{t} do

2:

N_{i}\gets Number of vertices in G_{p,i}

3:

v\gets \text {degree sequence of}~G_{p,i} \triangleright degree: number of edges connected to a vertex

4:

k\gets \text {histogram of}~v \triangleright count number of vertices for each degree between 0 and max(v)

5:

H_{i}\gets 0 \triangleright Initialize entropy value

6:

for c \text {in}~k do\triangleright c: # vertices associated with each degree value

7:

if c\gt 0 then

8:

p=c / N_{i} \triangleright probability of a vertex having degree k(c)

9:

H_{i}\gets H_{i}-p\cdot \log _{2}(p) \triangleright Iterative calculation of Shannon entropy

10:

end if

11:

end for

12:

end for

B. Knowledge Graph Modularity

The modularity property of each knowledge graph can be considered as a proxy for the respective power and propulsion systems’ modularity and is therefore indicative for the seamless adaptability of a vessel to a new mission. Let us consider power and propulsion plants to be undirected, unweighted networks (stemming from information stored in G_{p,i} ) with homogeneous vertices and edges. Then modularity is defined as follows.

Definition 2 (Network Modularity):

A measure of the quality of a particular division of a network [51].

The quality of this division is based on the number of edges within a certain module, community or division versus the number of edges between different communities. This modularity of each network G_{p,i} , denoted as Q_{i},\;i\in \{0,\ldots , N_{t}\} , is calculated as the sum over the communities, expressed as [51], [52]:\begin{equation*} Q_{i} = \frac {1}{2m_{i}} \sum _{c,i} \left ({{m_{c,i} - \frac {K_{c,i}^{2}}{4m_{i}} }}\right ), \tag {6}\end{equation*} View SourceRight-click on figure for MathML and additional features.where m_{c,i} is the number of internal edges (or total internal edge weight) of community c, m_{i} is the total number of edges of the network G_{p,i} and K_{c,i} = \sum _{i \mid \sigma _{i} = c} k_{i} is the total (weighted) degree of vertices in community c. This division is based on predefined communities (subgraphs) with dense network connections, while between communities sparse edges exist. Having clearly defined communities improves the quality of the knowledge graph modularity estimation. Exact community determination is a computationally hard problem, therefore, approximation algorithms such as the Girvan-Newman and Leiden algorithm, are necessary. Having an algorithm detect the communities may help uncover a priori unknown functional modules and aids in visualizing the network structure [53]. Here, the Leiden algorithm is selected for its strong properties in making well-connected communities. Moreover, finding communities could also provide a modular view of the network’s dynamics of functional separation [52]. In this study, the network community structure is not based on the flow types or vertex types within the network; only the overall network system architecture plays a role in defining the communities.

The Pareto optimal candidate system architecture decision is then based on two objectives (knowledge graph complexity and modularity), and is expressed as:\begin{equation*} \sigma _{d}= \arg \max _{i}\left ({{\left ({{Q_{i}^{2}H_{i}^{-2}}}\right )^{(1/2)}}}\right ), \tag {7}\end{equation*} View SourceRight-click on figure for MathML and additional features.where \sigma _{d}\in \mathbb {Z}_{+}^{N_{t}} corresponds to the selected system architecture adaptation i. Denoting the system architecture decision vector space as \Sigma _{d}~(\sigma _{d}\in \Sigma _{d}) , a mapping from the candidate layouts semantically described in {\mathcal {F}}_{p,i},\,i=1,\ldots , N_{t} to the selected systems for the system architecture {\mathcal {F}}_{p}^{(s)} can allow for an intelligent implementation of system architecture design decisions as follows:\begin{equation*} \Sigma _{d}\times \left ({{\bigcup _{i}{\mathcal {F}}_{p,i}}}\right )\mapsto {\mathcal {F}}_{p}^{(s)} \tag {8}\end{equation*} View SourceRight-click on figure for MathML and additional features.

SECTION V.

Intelligent Automation Supervisor

The decision on the optimal layout alteration \sigma _{d} , in terms of resulting “knowledge graph” modularity and complexity, and its mapping to the selected systems database {\mathcal {F}}_{p}^{(s)} in Section IV as well as the database of automation components {\mathcal {F}}_{A} are used to produce the semantic database \mathcal {F} according to (5). The knowledge graph G corresponding to the multi-level control scheme can also be extracted using Algorithm 1. Using the available semantic knowledge, expressed by \mathcal {F} , G and the Quality of Service (QoS) criteria, and the power profile of the mission P_{tot} , defined in (3), an intelligent automation supervisor is designed to determine the power deficit needed to execute a new mission (offline calculation) and to switch between operating components in the multi-level control scheme during the power and propulsion plant operation (online mapping). The logic behind the offline and online implementation of the supervisor is shown in Figure 7 and further detailed in Algorithms 3, 4. Section V-A will elaborate over the decision logic block of the supervisor and Section V-B will discuss the switching logic block, as seen in Figure 7. Finally, Section V-C will explain the multi-level vessel operation and its connection to the intelligent automation supervisor.

FIGURE 7. - Internal structure of the intelligent automation supervisor. A decision logic is implemented to match the power demand (power profile) with the onboard power supply (power and propulsion plant) and potentially to initialise system architecture adaptations by the vessel designers. The specifics of the decision logic are provided Algorithm 3. A switching logic is then implemented with two degrees of freedom; switching between hardware and virtual sensors and switching between energy management controllers during the plant operation. The specifics of the switching logic are provided in Algorithm 4. Continuous lines indicate signals that get updated during operation and dashed lines indicate signals that get updated between missions.
FIGURE 7.

Internal structure of the intelligent automation supervisor. A decision logic is implemented to match the power demand (power profile) with the onboard power supply (power and propulsion plant) and potentially to initialise system architecture adaptations by the vessel designers. The specifics of the decision logic are provided Algorithm 3. A switching logic is then implemented with two degrees of freedom; switching between hardware and virtual sensors and switching between energy management controllers during the plant operation. The specifics of the switching logic are provided in Algorithm 4. Continuous lines indicate signals that get updated during operation and dashed lines indicate signals that get updated between missions.

SECTION Algorithm 3

Decision Logic of the Intelligent Automation Supervisor (Offline) Drafted in Figure 7

Input:

P_{tot}(t), \; QoS, \; \mathcal {F}~\triangleright Power profile, qualitative plant model (Section III)

Design parameters: \alpha \in [{0,1}]~\triangleright Target generator sets utilisation factor

Output:

\Delta E~\triangleright Deficit in available power

1:

P_{tot}(t) \rightarrow P_{D}(t) + P_{aux}(t) \triangleright Split power profile in propulsion and auxiliary power

2:

P_{D,elec}(t) = {}\frac {P_{D}(t)}{\eta _{T}\eta _{EM}} \triangleright Propulsion power to electric power conversion

3:

P_{elec}(t) = P_{D,elec}(t) + P_{aux}(t)~\triangleright Total power demand of the power profile

4:

P_{ED}(t) = \sum ^{I}_{i=1} P_{ED,i}(t)~\triangleright Total power demand of induction motors

5:

P_{GS}(t) = \sum ^{J}_{n=1} P_{GS,j}^{opt}(t)~\triangleright Total genset power under optimal operation

6:

P_{demand}(t) = \mathbf {min}\left ({{0,\mathbf {max}(P_{elec}(t),P_{ED}(t)) - \alpha \cdot P_{GS}(t)}}\right )~\triangleright Power for the electric power demand

7:

E_{demand} = \int _{t=0}^{T} P_{demand}(t)

8:

Detemine E_{supply} using the semantic information for the available power and propulsion plant systems \mathcal {F} and their sizing in QoS

9:

\Delta E = E_{supply} - E_{demand} \triangleright Energy deficit calculation

10:

if \Delta E \lt 0 then \triangleright Power and propulsion plant can not match the desired power profile

11:

Output \gets |\Delta E|

12:

Output is provided to the operators and then the vessel designers to proceed with system architecture adaptations.

13:

else

14:

No system architecture adaptation is needed. Continue to operation in the specified mission.

15:

end if

SECTION Algorithm 4

Switching Logic of the Intelligent Automation Supervisor (Online) Drafted in Figure 7

Input:

\mathcal {F}, \; G,\;\mathcal {S}^{F}~\triangleright semantic database, knowledge graph and faulty sensor set

Output:

\mathcal {I}~\triangleright Active control configuration

1:

K\gets number of battery entries in \mathcal {F}

2:

\sigma \gets [1_{2K}^{\top } ;\;K] \triangleright Each battery has one voltage and one current sensor (models in Appendix- A)

3:

for voltage sensors \in {\mathcal {F}}_{s} do

4:

if voltage sensor of battery \{k\}~\in ~\mathcal {S}^{F} then \triangleright k=1,\ldots ,K

5:

\sigma (2k-1) \gets 2~\triangleright Switch to virtual voltage sensor with index 2

6:

end if

7:

end for

8:

for current sensors \in {\mathcal {F}}_{s} do

9:

if current sensor of battery \{k\}~\in ~\mathcal {S}^{F} then \triangleright k=1,\ldots ,K

10:

\sigma (2k) \gets 2~\triangleright Switch to virtual current sensor with index 2

11:

end if

12:

end for

13:

try\triangleright Mapping to the active control configuration

14:

\Sigma \times \mathcal {F} \mapsto \mathcal {I}~\triangleright \Sigma : vector space of decisions \sigma

15:

Output\gets \mathcal {I}

16:

except \triangleright Graph unavailability, mapping not feasible

17:

Determine unavailable part of Graph G

18:

\sigma (2K+1) \gets \sigma (2K+1)-1

19:

go to 27

20:

end try

A. Offline Decision Logic

As indicated in Figure 7, the goal of the decision logic block is (i) to determine whether the input power profile can be executed with the available power supply systems and (ii) otherwise, to determine the current deficit in the required power expressed as \Delta E=E_{supply}-E_{demand} , where E_{supply} denotes the available energy using the existing power and propulsion plant system architecture and sizing and E_{demand} denotes the energy demand as indicated by the power profile. This deficit is then reported to the vessel operators and used as input by the designers to determine certain candidate system architecture adaptations.

Due to the hybrid nature of the propulsion system, the total power profile P_{tot} is expected to be served by both mechanical (e.g., internal combustion engine) and electrical (e.g., induction motor, generator sets, batteries) energy systems. In order to make comparisons easier, the power profile is divided in two parts, the required propulsion P_{D} and auxiliary P_{aux} power profiles in line 1 of Algorithm 3 and a total - only electric- power profile is reformed in lines 2 -3. The required energy demand E_{demand} is calculated in lines 4- 7 and is based on a design parameter \alpha , expressing the utilisation factor of the generator sets during operation in the requested power profile. A value of \alpha =0 indicates high energy redundancy and sustainability targets in the design (both generator sets are in reserve) while a value of \alpha =1 leads to less additional energy storage requirements and subsequently less retrofit costs (both generators are expected to be used at their optimal operation point). Using this and information on the energy supply already present in the vessel system architecture (P_{supply} specified in the QoS criteria), the difference in energy \Delta E is calculated in line 9. If \Delta E \lt 0 , an energy deficit is indicated and adaptations on the power and propulsion plant are requested by the vessel designers. In any other case, the installed power and propulsion plant is considered sufficient to handle the mission and online operation is resumed. The aforementioned logic can also be seen in Algorithm 4.

B. Online Switching Logic

During the power and propulsion plant operation, multiple vulnerabilities such as sensor faults can negatively affect onboard safety. As a result, we design the logic of the intelligent automation supervisor to switch between hardware and virtual sensors, when one or more sensor faults affect the onboard energy storage devices, and between secondary level controllers, when access and control are denied to part of the energy storage. In lines 1-2 of Algorithm 4 the number of available batteries is determined using the component database \mathcal {F} . Considering that each energy storage device is equipped with one voltage and one current sensor, a switching vector is defined as \sigma \in \mathbb {Z}_{+}^{2K+1} , where K is the number of batteries. Using the feedback of the monitoring agents regarding the set of faulty sensors \mathcal {S}^{F} the switching between hardware voltage and current sensors (index =1) and their virtual counterparts (index =2) is translated to adaptations in the respective elements of the switching vector \sigma in lines 3-12. The mapping of the switching vector space \Sigma ~(\sigma \in \Sigma ) to the active automation configuration \mathcal {I} using the semantic database \mathcal {F} is attempted in lines 13-15, where the unavailability of certain graph components is assumed. In this case, the supervisor determines the inaccessible part of the power and propulsion plant through the knowledge graph G and updates the choice of secondary level controller in the switching vector \sigma in lines 16-18. The mapping to the active control configuration is re-attempted until the implementation of the switching decision vector \sigma is feasible, as is also seen in lines 19-20.

C. Multi-Level Vessel Operation

Marine vessel control systems are usually composed of two control levels; the primary and secondary control level. In Figure 8, a simplified control layout showing the interaction between the two control levels is provided, considering the hybrid power and propulsion plant system architecture shown in Figure 4(a).

FIGURE 8. - Multi-level power and propulsion plant control scheme overview.
FIGURE 8.

Multi-level power and propulsion plant control scheme overview.

The primary level includes the local controllers for the internal combustion engine (ICE), the induction motor, the generator sets and the batteries. Model-free PI controllers are designed while the batteries are controlled using battery constraint modules [22]. For propulsion, a parallel control approach is adopted with torque control designed for the ICE and speed control applied to the induction motor [54]. In the secondary control level, an energy management controller is designed to handle the power split between the different systems and provide the appropriate reference signals to the primary level controllers, as can be seen in Figure 8. The input to this level is the propulsion and auxiliary power demand, as extracted by the power profile.

The intelligent automation supervisor we propose in this work has the ability to switch between different energy management controllers in case of unavailability of graph components (e.g., a battery is not responding due to a software issue). The relevant decision is included as the last element \sigma (2K+1) of the decision vector of the supervisor and is implemented through the mapping \Sigma \times \mathcal {F} \mapsto \mathcal {I} . Finally, the communication from the primary to the secondary control level is enabled using the feedback measurement signals of the active, either hardware or virtual, sensors as these are determined by the switching logic of the intelligent supervisor.

For the sake of brevity, in this work we consider only sensor faults in the energy storage devices. As a result, monitoring agents and virtual sensors are generated only for the energy storage. The reader can find more information on the design of the design of the monitoring agents and virtual sensors in [39], [55]. Each secondary level controller is composed of an equivalent consumption minimisation problem with cost function and constraints described as follows, in cases only batteries are considered [22]:\begin{equation*} \min \{\dot {m}_{T,K}|\;\mathcal {I}\}, \tag {9}\end{equation*} View SourceRight-click on figure for MathML and additional features.where\begin{align*}& \hspace {-1.2pc}\dot {m}_{T,K} = a^{ICE}_{1} \cdot {P_{ICE}}^{3} + a^{ICE}_{2} \cdot {P_{ICE}}^{2} + a^{ICE}_{3} \cdot \omega _{ICE}^{2}\cdot P_{ICE} \\& {}+ a^{ICE}_{4} \cdot \omega _{ICE}\cdot P_{ICE}+ a^{ICE}_{5} \cdot {P_{ICE}}^{2} + a^{ICE}_{6}\cdot P_{ICE}\cdot \omega _{ICE} \\& {}+ \underbrace {\sum ^{2}_{j=1}\left ({{a^{GS,j}_{1} \cdot \left ({{\frac {P_{GS,j}}{\eta _{GS,j}}}}\right )^{3} + a^{GS,j}_{2} \cdot \left ({{\frac {P_{GS,j}}{\eta _{GS,j}}}}\right )^{2} + a^{GS,j}_{3} \cdot {\frac {P_{GS,j}}{\eta _{GS,j}}} }}\right )}_{ \text {Fuel consumption rate of fixed plant systems}~} \\& {}+ \underbrace {\sum ^{\boldsymbol {\sigma (2K+1)}}_{k=1}\left ({{{SFOC_{ICE,nom} \cdot {\eta _{FC}} \cdot \eta _{IM} \cdot {\eta _{B,k}}^{sign\left ({{P_{B,k}}}\right )}} \cdot {P_{B,k}}}}\right )}_{ \text {Fuel consumption rate of adapted systems according to}\;{ \mathcal {I}}}, \tag {10}\end{align*} View SourceRight-click on figure for MathML and additional features.subject to the following constraints:\begin{align*}& P_{ICE} \geq \frac {P_{D}}{\eta _{T}} - P_{IM,mec}, \tag {11}\\& \sum _{j=1}^{2}P_{GS,j} \geq P_{aux} - \sum _{k=1}^{K}P_{B,k} + \frac {P_{IM,mec}}{\eta _{IM}\cdot \eta _{FC}}, \tag {12}\\& 0 \leq P_{ICE} \leq P_{ICE}^{max}, \tag {13}\\& 0 \leq P_{IM,mec} \leq P_{IM,mec}^{max}, \tag {14}\\& 0 \leq P_{GS,j} \leq P_{GS,j}^{max},~j \in [{1,2}], \tag {15}\\& P_{B,k}^{min} \leq P_{B,k} \leq P_{B,k}^{max},~k \in \left [{{1,\ldots , \boldsymbol {\sigma (2K+1)}}}\right ], \tag {16}\\& P_{B,k} \geq P_{B,k-1},~k \in \left [{{2,\ldots , \boldsymbol {\sigma (2K+1)}}}\right ], \tag {17}\\& P_{B,K} \cdot P_{B,1} \geq 0,~\text {if}~\boldsymbol {\sigma (2K+1)}\geq 2. \tag {18}\end{align*} View SourceRight-click on figure for MathML and additional features.

The term \dot {m}_{T,K} is the fuel consumption rate for a power and propulsion plant with K batteries in [kg/sec], P_{ICE},P_{IM,mec},P_{GS,j} , and P_{B,k} denote the power split regarding the diesel engine, induction motor, diesel generator set j \in [{1,2}] , and battery k\in [1,\ldots , K] , respectively, with limits P_{ICE}^{max} , P_{IM,mec}^{max} , P_{GS,j}^{max} , P_{B,k}^{min} , and P_{B,k}^{max} . Furthermore, a_{i}^{ICE} for i \in \{1,2,3,4,5,6\} , a_{i}^{GS,j} for i \in \{1,2,3\} are constants to characterize the fuel consumption, SFOC_{ICE,nom} is the nominal diesel engine fuel consumption, \eta _{B,k} is the efficiency of battery k, and \eta _{GS,j} the j-th diesel generator set’s efficiency. The effect of the active configuration \mathcal {I} on the ECMS controller is highlighted with a bold font. In addition, the intelligent supervisor ensures that only healthy measurements are given as feedback to the secondary level controller as can be seen in Figure 8 where the notation y^{(I)}_{H}(t) is used to denote the healthy measurement of the quantity originally measured by y^{(I)}(t),\;I=1,\ldots , N .

Using the above optimization problem for the ECMS, the power for each component is found, at each moment during the mission. This can be used to derive the following reference signals for the primary level: torque of the diesel engine ref^{(1)}\in \mathbb {R} , rotor speed for the induction motor ref^{(2)}\in \mathbb {R} , voltage and shaft speed of each diesel generator set ref_{j}^{(4)}(t)\in \mathbb {R}^{2} , respectively for j \in \{1,\,2\} , and the reference power of the K batteries, ref^{(5)}(t)\in \mathbb {R} . The reference signals are calculated as follows:\begin{align*} ref^{(1)}(t)=& \frac {P_{ICE}}{ref^{(2)}(t)}\cdot \frac {i_{IM}}{i_{ICE}}, \tag {19}\\ ref^{(2)}(t)=& i_{IM}\cdot \sqrt [{3}]{\frac {P_{D}}{C_{p}}}, \tag {20}\\ ref_{j}^{(4)}(t)=& \left [{{V_{grid},\;\;f_{grid} \cdot \frac {4\pi }{p_{GS,j}}}}\right ]^{\top },\; j\in \{1,\,2\}, \tag {21}\\ ref^{(5)}(t)=& P_{B}, \tag {22}\end{align*} View SourceRight-click on figure for MathML and additional features.where C_{p} is the propeller constant, i_{IM} and i_{ICE} the induction motor and diesel engine gear ratios, V_{grid} and f_{grid} the required grid voltage and frequency, and p_{GS,j} the number of poles of generator set j.

SECTION VI.

Mission-Adaptive Tugboat Case Study

For illustrating the efficiency of the developed framework to enable modularity in system architecture and control of marine vessels, we consider a tugboat application on the Smith Elbe vessel [31]. A typical mission for a tugboat consists of the following five operational modes: (i) Transit to the arrival location of the cargo vessel to be towed, (ii) remain standby at position until the cargo vessel arrives, (iii) assist-low, (iv) assist-high, in order to guide the cargo vessel into the harbour, and (v) transit back to a specific location in the harbour when finished. For this case study, a baseline mission, Mission 1, with an associated power profile, Power profile 1, is used for the vessel, found in [56] and shown in Figure 9. Based on the power requirements of this power profile (blue continuous and red dash-dotted curves in Figure 9), the initial power and propulsion plant layout of the tugboat corresponds to the layout shown in Figure 4(a) with the associated “knowledge graph” as shown in Figure 4(b).

FIGURE 9. - Power profiles of two missions with different power requirements.
FIGURE 9.

Power profiles of two missions with different power requirements.

FIGURE 10. - Modularity and Complexity of the base system architecture compared to the three alternative architectures as those are defined in Figure 5. The battery addition system architecture 
$\sigma_{d}=1$
 provides the only increase in modularity out of the available options with just a small decrease in complexity (Pareto optimal).
FIGURE 10.

Modularity and Complexity of the base system architecture compared to the three alternative architectures as those are defined in Figure 5. The battery addition system architecture \sigma_{d}=1 provides the only increase in modularity out of the available options with just a small decrease in complexity (Pareto optimal).

For Mission 1, the initial multi-level control system is semantically described and incorporates one secondary level controller, the primary level controllers, monitoring agents, hardware and virtual sensors as seen in Figure 11(a). Now, let’s suppose that due to having a larger cargo vessel to assist and high demand for tugboats in port at a specific time period, the required propulsion power P_{D} increases. Using (2), the new propulsion power profile for Mission 2 can be estimated, resulting in Figure 9 with a magenta dashed line. For the sake of simplicity, we assume that the power demand for auxiliary power P_{aux} remains the same for the two missions. Using the decision logic of the intelligent automation supervisor between the two missions (Algorithm 3) with \alpha =0.5 (only one generator set would be in use), it is deduced that the current power and propulsion plant has a power deficit of \Delta E=-1080\;MJ and as a result the system architecture of the power and propulsion plant needs to be modified to handle Mission 2.

FIGURE 11. - Complete knowledge graphs G including both the system and automation vertices V and edges E for (a) the initial power and propulsion plant layout and (b) the selected power and propulsion plant system architecture using additional battery storage 
$(\sigma _{d}=1)$
. The different colours of edges indicate the use of different mediums 
$\Upsilon $
.
FIGURE 11.

Complete knowledge graphs G including both the system and automation vertices V and edges E for (a) the initial power and propulsion plant layout and (b) the selected power and propulsion plant system architecture using additional battery storage (\sigma _{d}=1) . The different colours of edges indicate the use of different mediums \Upsilon .

A. System Architecture Adaptation Decision

Using Algorithm 1, the knowledge graphs corresponding to the candidate power and propulsion plant architectures (Figures 5(a)–​5(c)) are constructed. Since we aim for high modularity and low complexity, the Pareto optimal (see (7) shows values in the lower right corner of the figure. Since modularity can be negative when more edges exist between communities than within communities, the values are squared as shown in (7). According to these metrics, the candidate system architecture with the highest modularity and lowest increase in complexity compared to the base knowledge graph is \sigma _{d}=1 (battery addition).

B. Online Reconfiguration Decisions Under the Effects of Sensor Faults and Graph Unavailability

After deciding on the optimal system architecture adaptation, the semantic database is updated with the additional automation components. More precisely, an additional energy management controller (K=2) is designed to be able to utilise both the original (\Sigma ^{(5)}) and the additional (\Sigma ^{(6)}) energy storage. The original secondary level controller (K=1) also remains available as part of the semantic database in case of unavailability of certain graph components. In addition, the monitoring system is enhanced with the addition of an agent monitoring the health of the sensors included with the additional battery stack. The complete knowledge graph accounting for both system and automation components is shown in Figure 11(b).

For the simulation scenario in Mission 2 we consider that the power and propulsion plant is affected by two sensor faults, occurring at T_{f1}^{(5)}=20\;min and T_{f2}^{(6)}=60\;min in the current sensor \mathcal {S}^{(5)}\{1\} of the first battery and the voltage sensor \mathcal {S}^{(6)}\{2\} of the second battery with magnitudes of f_{1}^{(5)}=-60\; A and f_{2}^{(5)}=40\;V accordingly. Moreover, at T_{G}^{(6)}=100\; min battery 2 can no longer be reached due to graph unavailability. The illustration of the simulation scenario with reference to the knowledge graph is shown in Figure 12. In order to simulate the behavior of the marine power and propulsion plant under the aforementioned conditions, the models described in Appendix- A are used. The simulation results for the specified scenario are shown in Figures 13–​14.

FIGURE 12. - Simulation scenario representation with indicated vulnerabilities affecting the power and propulsion plant using the knowledge graph in Figure 11(b). The hardware sensor vertices affected by faults are highlighted with a red encompassing circle and the vertices under graph unavailability are highlighted with a black encompassing circle and dash-dotted connection edges.
FIGURE 12.

Simulation scenario representation with indicated vulnerabilities affecting the power and propulsion plant using the knowledge graph in Figure 11(b). The hardware sensor vertices affected by faults are highlighted with a red encompassing circle and the vertices under graph unavailability are highlighted with a black encompassing circle and dash-dotted connection edges.

The switching vector \sigma , derived using the switching logic of the intelligent automation supervisor (Algorithm 4), can be seen in Figure 13. Since only sensor faults in the onboard batteries are considered and the number of batteries is K=2 , the switching vector \sigma is composed of 5~(2K+1) elements. The decision on which battery current sensor to use (hardware or virtual) is contained in \sigma (1) for Battery 1 and \sigma (3) for Battery 2. In a similar manner, \sigma (2) and \sigma (4) store the decision on which battery voltage sensor to use for Battery 1 and Battery 2, respectively. Finally, \sigma (5) stores the decision regarding the secondary level controller to use.

FIGURE 13. - Switching vector 
$\sigma $
 components for power profile 2 under the specified anomaly scenario. The decisions of the monitoring agents regarding sensor faults shown as a red dash-dotted line in subfigures (a)-(d) activates the switching from hardware sensors with index 1 to virtual sensors with index 2 as can be seen with the black continuous lines on the same subfigures. Due to the unavailability of certain graph components, the supervisor switches the secondary level controller to utilise only the available energy storage as can be seen by the switching component 
$\sigma ^{(5)}$
 in Figure (e).
FIGURE 13.

Switching vector \sigma components for power profile 2 under the specified anomaly scenario. The decisions of the monitoring agents regarding sensor faults shown as a red dash-dotted line in subfigures (a)-(d) activates the switching from hardware sensors with index 1 to virtual sensors with index 2 as can be seen with the black continuous lines on the same subfigures. Due to the unavailability of certain graph components, the supervisor switches the secondary level controller to utilise only the available energy storage as can be seen by the switching component \sigma ^{(5)} in Figure (e).

As seen from Figures 13(a), (d) the two simulated faults are almost instantly diagnosed after their occurrence using the designed monitoring agents. The reader is encouraged to find more details and performance analysis characteristics for this design in [8]. At the same time, the respective element, \sigma (1) or \sigma (4) , of the switching vector changes from ‘1’ to ‘2’ indicating the switching between the “hardware” and “virtual” sensors. Since no sensor faults are detected in sensors \mathcal {S}^{(5)}\{2\} and \mathcal {S}^{(6)}\{1\} , the vector elements \sigma (2) and \sigma (3) remain the same and equal to ‘1’ indicating the use of hardware sensors, as shown in Figures 13(b), (c). Finally, aside from the monitoring agents, the feasibility of the mapping operation \Sigma \times \mathcal {F}\mapsto \mathcal {I} can alter the switching vector by switching between energy management controllers and rerouting the power split. This can be seen in Figure 13(e) where, for the sake of notation, the feasibility of the mapping takes the value ‘1’ when applicable and ‘0’ otherwise. At t=100\;min , the graph unavailability takes place and element \sigma (5) changes from K=2 to K=1 so that only one battery can still be used.

Figure 14 shows the tracking performance of the power profile using the proposed multi-level control scheme and the switching logic of the intelligent automation supervisor. Aside from the transient behavior encountered for t\leq 10\;min and the rerouting of power at t=100\;min due to the graph unavailability, the power and propulsion plant manages to follow very closely the power profile. In particular, the normalised root mean square error (RMSE) between the power profile and the power output is used to assess the performance of the multi-level vessel operation block (Section V-C). For propulsion, an RMSE of 2% is attained while the RMSE for the auxiliary power corresponds to 1.82%. Finally, Figures 15(a), 15(b) show the power split found as the solution of the ECMS formulated problem previously explained in Section V-C. It can be seen from Figure 15(a) that throughout the mission, mostly the induction motor is used while the internal combustion engine is activated only during the peak of the power profile (90\;min\leq t \leq 110\;min) , thus promoting sustainability. The switching of the secondary level controller affects the split to the induction motor since this is connected to the available energy storage. The power split between the generator sets and the batteries is then shown in Figure 15(b). The first generator set supplies most of the power throughout the vessel mission (black continuous line in Figure 15(b)) with the two batteries activated at higher power loads occurring from t\geq 60\;min in the power profile for mission 2 shown in Figure 9. The graph unavailability affecting battery 2 from t\geq 100\;min leads to controller switching and battery 2 not being in use after that moment (red dash-dotted line in Figure 15(b). Subsequently, battery one assumes a higher load (blue dashed line in Figure 15(b)) until the power demand decreases at t\geq 110\;min and battery charging is preferred, as indicated by the negative sign of the battery power. Generator 2 in this case (\alpha =0.5) indeed remains inactive during the whole mission, further advocating for increased sustainability in the power and propulsion plant operation under the implemented system architecture and control adaptations.

FIGURE 14. - Reference and achieved power profile using the base power and propulsion plant layout and ECMS for K=2 batteries. The reference signals for the secondary level, regarding the required propulsion 
$P_{D}$
 and auxiliary 
$P_{aux}$
 power are shown with continuous lines. Dashed lines showcase the performance of the multi-level control system to track power profile 2.
FIGURE 14.

Reference and achieved power profile using the base power and propulsion plant layout and ECMS for K=2 batteries. The reference signals for the secondary level, regarding the required propulsion P_{D} and auxiliary P_{aux} power are shown with continuous lines. Dashed lines showcase the performance of the multi-level control system to track power profile 2.

FIGURE 15. - (a) Split of the required propulsion power into equivalent loadings of the internal combustion engine (black dashed line) and the induction motor (magenta continuous line), (b) Split of the required power on equivalent loadings of generator sets (black continuous and magenta dash-dotted lines) and the onboard battery stack (blue dashed and red dotted lines).
FIGURE 15.

(a) Split of the required propulsion power into equivalent loadings of the internal combustion engine (black dashed line) and the induction motor (magenta continuous line), (b) Split of the required power on equivalent loadings of generator sets (black continuous and magenta dash-dotted lines) and the onboard battery stack (blue dashed and red dotted lines).

SECTION VII.

Conclusion

In this paper, an intelligent agent-based resilient framework to support human actors in marine vessel mission adaptations is proposed. The connection between adaptations in system architecture and control was rendered possible through the use of a qualitative knowledge-representation technique based on semantics. Two intelligent agents were designed to assist both the vessel designers and the operators. First, an intelligent decision support module was designed to select the optimal power and propulsion system architecture adaptations when the power requirements for the mission change. Second, an intelligent supervisor was developed to execute the following tasks; decide whether the power profile can be executed with the available equipment or not, and to switch between (a) hardware and virtual sensors or (b) between secondary level controllers, in case a combination of multiple sensor faults and graph unavailability is detected. The results from the tugboat case study demonstrate that the intelligent framework successfully manages to promote robustness against sensor noise and uncertainty and resilience regarding different adaptation scenarios in the marine power and propulsion plant. Tracking of the power profile is accomplished with minimal errors.

The framework is expected to facilitate day-to-day vessel operations, by enabling seamless system architecture adaptations to updated requirements. In actual implementation, the intelligent agents would (i) be realized in different hardware devices (i.e., computers of technical offices, onboard the vessel), (ii) operate at different time-scales (i.e., during operation, in-between missions), and (iii) communicate with each other with minimum delays. As a result, the choice of hardware that will enable proper and reliable coordination of the communicated information is crucial for the framework’s application. Moreover, the framework considers the involvement of multiple human actors (i.e., system designers, integrators, operators). Errors and/or delays in their communication should be handled to ensure the efficiency of the multi-level vessel operation. The efficiency in the decision-making in real implementation could be further improved by reducing the modelling uncertainty in the description of the system architecture and of the real operation. Future work will also involve addressing these implementation constraints.

Appendix

Differential-Algebraic Models of the Marine Power and Propulsion Plant

In this section, the Differential-Algebraic models of the power and propulsion plant systems and their parameters, used in this paper, are described. In general, marine vessel systems can be decomposed in subsystems \Sigma ^{(I)},\,I=1,\ldots , N that are characterised by Differential-Algebraic dynamics, mathematically described as:\begin{align*}& \dot {x}^{(I)}(t) {=}A^{(I)}x^{(I)}(t) {+}\gamma ^{(I)}(x^{(I)}(t),z^{(I)}(t),u^{(I)}(t)) \\ {}\smash {\left \{{\vphantom {\begin{matrix}.\\ .\\ .\\ .\\ .\\ \end{matrix}}}\right .}& +h^{(I)}(x^{(I)}(t),z^{(I)}(t),\chi ^{(I)}(t),u^{(I)}(t)), \tag {23a}\\ & 0=\xi ^{(I)}(x^{(I)}(t),z^{(I)}(t),\chi ^{(I)}(t),u^{(I)}(t)), \tag {23b}\end{align*} View SourceRight-click on figure for MathML and additional features.where x^{(I)} \in \mathbb {R}^{n_{I}-r_{I}} is the state variable vector, z^{(I)} \in \mathbb {R}^{r_{I}} is the algebraic variable vector, \chi ^{(I)} \in \mathbb {R}^{k_{I}} are the interconnection variables from the neighbouring subsystems, u^{(I)} \in \mathbb {R}^{l_{I}} is the control input vector, \gamma ^{(I)}~:~\mathbb {R}^{n_{I}-r_{I}}\times \mathbb {R}^{l_{I}}\mapsto \mathbb {R}^{n_{I}-r_{I}} represents the known nonlinear system dynamics, h^{(I)}~:~\mathbb {R}^{n_{I}-r_{I}}\times \mathbb {R}^{r_{I}} \times \mathbb {R}^{k_{I}} \times \mathbb {R}^{l_{I}}\mapsto \mathbb {R}^{n_{I}-r_{I}} represents the known interconnection dynamics with the neighbouring subsystems, \xi ^{(I)}: \mathbb {R}^{n_{I}}\times \mathbb {R}^{k_{I}} \times \mathbb {R}^{l_{I}}\mapsto \mathbb {R}^{n_{I}-r_{I}} is a smooth vector field. The term A^{(I)}x^{(I)} represents the linear part of the system’s \Sigma ^{(I)} dynamics, where A^{(I)}\in \mathbb {R}^{(n_{I}-r_{I})\times (n_{I}-r_{I})} is assumed known. Each subsystem \Sigma ^{(I)},\,I=1,\ldots , N incorporates a set of hardware sensors \mathcal {S}^{(I)}=\bigcup _{k=1}^{n_{I}}\mathcal {S}^{(I)}\{k\} described as:\begin{align*} \mathcal {S}^{(I)}~: ~y^{(I)}(t)= C^{(I)}\cdot \left [{{\begin{array}{c} x^{(I)}(t) \\ z^{(I)}(t) \end{array}}}\right ]+d^{(I)}(t)+f^{(I)}(t), \tag {24}\end{align*} View SourceRight-click on figure for MathML and additional features.where y^{(I)}\in \mathbb {R}^{m_{I}} denotes the hardware sensor measurements, C^{(I)}\in \mathbb {R}^{m_{I}\times n_{I}} is the observability matrix, d^{(I)}\in \mathbb {R}^{m_{I}} are the measurement noise vectors and f^{(I)} \in \mathbb {R}^{m_{I}} are the sensor fault vectors. Each fault vector is given by f^{(I)}(t)=[f^{(I)}_{1}(t),\ldots , f^{(I)}_{m_{I}}(t)]^{\top } , where f^{(I)}_{k}(t), k\in \{1,\ldots , n_{I}\} denotes the change in the output due to a fault in the k-th hardware sensor. The differential-algebraic system formulation used in the scope of this paper is based on the first principle models described in [22]. The models, employing the general Differential-Algebraic formulation described in (23a)–​(24), are presented in the following subsections.

SECTION A.

Internal Combustion Engine (\Sigma ^{(1)})

The dynamic operation of the diesel engine is expressed as a first-order differential equation [57]:\begin{align*} \Sigma ^{(1)}~:~\dot {x}^{(1)}(t)=\gamma ^{(1)}\left ({{x^{(1)},u^{(1)}}}\right )+h^{(1)}\left ({{x^{(1)},\chi ^{(1)},u^{(1)}}}\right ), \tag {25}\end{align*} View SourceRight-click on figure for MathML and additional features.where\begin{align*} \begin{cases} \gamma ^{(1)}\left ({{x^{(1)},u^{(1)}}}\right )=k_{ICE} \cdot u^{(1)}(t), \\ h^{(1)}\left ({{x^{(1)},\chi ^{(1)},u^{(1)}}}\right )=-\frac {i_{ICE}}{0.9}\cdot x^{(3)}(t)\cdot x^{(1)}(t), \end{cases} \tag {26}\end{align*} View SourceRight-click on figure for MathML and additional features.,x^{(1)}\in \mathbb {R} denotes the torque of the internal combustion engine [Nm], \chi ^{(1)}(t)=x^{(3)}(t) is the propeller speed [rps] and serves as the interconnection state between \Sigma ^{(1)} and \Sigma ^{(3)} , k_{ICE} is the torque constant, i_{ICE} is the gearbox ratio of the diesel engine and u^{(1)}(t) is the control input and expresses the fuel index [kg of fuel]. The engine is equipped with a torque hardware sensor, mathematically expressed as:\begin{equation*} \mathcal {S}^{(1)}~:~y^{(1)}(t)=x^{(1)}(t)+d^{(1)}(t)+f^{(1)}(t), \tag {27}\end{equation*} View SourceRight-click on figure for MathML and additional features.where d^{(1)}(t),\,f^{(1)}(t)\in \mathbb {R} .

SECTION B.

Induction Motor (\Sigma ^{(2)})

The operation of the induction motor can be described as [58]:\begin{equation*} \Sigma ^{(2)}~:~ 0=\xi ^{(2)}\left ({{z^{(2)},\chi ^{(2)},u^{(2)}}}\right ), \tag {28}\end{equation*} View SourceRight-click on figure for MathML and additional features.where\begin{align*} \xi ^{(2)}\left ({{t}}\right )=\frac {p}{4\pi i_{gb}x^{(3)}}\frac {\left ({{u^{(2)}}}\right )^{2}}{\left ({{\frac {R_{2}}{s}}}\right )^{2}+\left ({{\frac {i_{gb}x^{(3)}}{2\pi }\left ({{H_{s}+H_{r}}}\right )}}\right )^{2}}\frac {R_{r}}{s}-z^{(2)}, \tag {29}\end{align*} View SourceRight-click on figure for MathML and additional features.p denotes the number of poles, \chi ^{(2)}=x^{(3)}\in \mathbb {R} is the rotational speed of the propeller shaft in [rps] and serves as the interconnection state between \Sigma ^{(2)} and \Sigma ^{(3)} , u^{(2)} is the control value expressing the input voltage, s is the slip, R_{r} is the rotor resistance in [\Omega ] and H_{s},H_{r} are the stator and rotor reluctance in [H] respectively. The output of the induction motor torque sensor y^{(2)}\in \mathbb {R} is described by:\begin{equation*} {S}^{(2)}~:~y^{(2)}=z^{(2)}+d^{(2)}+f^{(2)}. \tag {30}\end{equation*} View SourceRight-click on figure for MathML and additional features.

SECTION C.

Gearbox, Shaft, and Propeller (\Sigma ^{(3)})

The shaft dynamics of the gearbox, shaft and propeller, are expressed as [57]:\begin{equation*} \Sigma ^{(3)}~: ~\dot {x}^{(3)}(t) = \gamma ^{(3)}\left ({{x^{(3)}(t)}}\right )+h^{(3)}\left ({{x^{(3)}(t),\chi ^{(3)}(t)}}\right ), \tag {31}\end{equation*} View SourceRight-click on figure for MathML and additional features.where\begin{align*} \begin{cases} \gamma ^{(3)}\left ({{t}}\right )=-\frac {C_{p}}{J_{tot}} \cdot \left ({{x^{(3)}(t)}}\right )^{2}, \\ h^{(3)}\left ({{t}}\right )=\frac {\eta _{T}}{J_{tot}}\left ({{i_{ICE}\cdot x^{(1)}(t)+i_{IM}\cdot z^{(2)}(t)}}\right ), \end{cases} \tag {32}\end{align*} View SourceRight-click on figure for MathML and additional features.x^{(3)}(t)\in \mathbb {R} denotes the propeller shaft rotational speed [rps], \chi ^{(3)}(t)=[x^{(1)}(t);z^{(2)}(t)]^{\top }\in \mathbb {R}^{2} are the interconnection states between \Sigma ^{(3)} and \Sigma ^{(1)},\Sigma ^{(2)} , J_{tot} is the total inertia of the gearbox [kg\cdot m^{2} ], induction machine and the diesel engine together and \eta _{T} denotes the efficiency of the transmission system. A shaft speed sensor is installed in this system and expressed as follows:\begin{equation*} \mathcal {S}^{(3)}~:~y^{(3)}=z^{(3)}+d^{(3)}+f^{(3)},\; \tag {33}\end{equation*} View SourceRight-click on figure for MathML and additional features.with d^{(3)}(t),f^{(3)}(t)\in \mathbb {R} .

SECTION D.

Generator Sets (\Sigma ^{(4)})

Each generator set is modeled as follows [57], [59]:\begin{align*} \Sigma ^{(4)}~:~\begin{cases} \dot {x}^{(4)}(t) = \gamma ^{(4)}\left ({{x^{(4)}(t),z^{(4)}(t), u^{(4)}(t)}}\right ) \\ 0=\xi ^{(4)}\left ({{x^{(4)}(t),z^{(4)}(t)}}\right ) ,\end{cases} \tag {34}\end{align*} View SourceRight-click on figure for MathML and additional features.where\begin{align*} \gamma ^{(4)}\left ({{t}}\right )=& \left [{{\begin{array}{c} -\frac {10}{9}\cdot x_{1}^{(4)}(t)\cdot x_{2}^{(4)}(t)+k_{GS} \cdot u^{(4)}(t) \\ \frac {1}{J_{GS}} \left ({{x_{1}^{(4)}(t)-z_{1}^{(4)}(t)}}\right ) \end{array}}}\right ], \tag {35}\\ \xi ^{(4)}\left ({{t}}\right )=& \left [{{\begin{array}{cc} \frac {\left ({{a_{G,1} \cdot I_{X}(t) + a_{G,0}}}\right ) \cdot Re\left ({{z_{2}^{(4)}(t)}}\right )}{2\pi }-z_{1}^{(4)}(t) \\ \frac {\left ({{a_{G,1} \cdot I_{X}(t) + a_{G,0}}}\right ) \cdot x_{2}^{(4)}(t)}{2\pi (R_{GS,int} + j \cdot L_{GS} \cdot \omega _{GS}(t) + R_{GS}(t)} -z_{2}^{(4)}(t) \end{array}}}\right ], \tag {36}\end{align*} View SourceRight-click on figure for MathML and additional features.x^{(4)}(t)=[x_{1}^{(4)}(t);x_{2}^{(4)}(t)]^{\top }\in \mathbb {R}^{2} , z^{(4)}(t)=[z_{1}^{(4)}(t);z_{2}^{(4)}(t)]^{\top }\in \mathbb {R}^{2} , x_{1}^{(4)} denotes the torque of the internal combustion engine driving the generator set [Nm ], x_{2}^{(4)} is the rotational speed of the generator’s shaft [rps ], z_{1}^{(4)} denotes the torque of the generator part in the generator set[Nm ], z_{2}^{(4)} is the generator output current [A], k_{GS} the torque constant, m_{f,GS} [kg\; fuel ] is the fuel index (regulated by a PI controller), I_{X} [A]the excitation current, a_{G,1} and a_{G,0} are constants, R_{GS,int} [\Omega ] the internal resistance, L [H] the inductance, j the imaginary number, and J_{GS} [kg\cdot m^{2} ] the generator inertia. In this work, the load resistance R_{GS} [\Omega ] is assumed to be purely resistive, and determined with the assigned power P_{GS} [W] (given by the secondary level controller) and the reference-voltage V_{GS,ref} [V] as follows:\begin{equation*} R_{GS}(t) = \frac {V_{GS,ref}^{2}(t)}{P_{GS}(t)}. \tag {37}\end{equation*} View SourceRight-click on figure for MathML and additional features.The engine is equipped with two torque sensors (one for the engine output and one for the generator input), a shaft speed sensor installed on the generator set shaft and a current sensor measuring the output current. The aforementioned hardware sensors are mathematically expressed as:\begin{align*} \mathcal {S}^{(4)}~:~y^{(4)}(t)=\left [{{\begin{array}{c} x^{(4)}(t) \\ z^{(4)}(t) \end{array}}}\right ]+d^{(4)}(t)+f^{(4)}(t),\, \tag {38}\end{align*} View SourceRight-click on figure for MathML and additional features.with d^{(4)}(t),\,f^{(4)}(t)\in \mathbb {R}^{4} .

SECTION E.

Batteries and Constraint Modules (\Sigma ^{(5)} and \Sigma ^{(6)})

Batteries can be mathematically described as follows [60]:\begin{align*} \Sigma ^{(5)}~:~\begin{cases} x^{(5)}(t)=\gamma ^{(5)}\left ({{z^{(5)}(t)}}\right ) \\ 0=\xi ^{(5)}\left ({{x^{(5)}(t),z^{(5)}(t),u^{(5)}(t)}}\right ),\end{cases} \tag {39}\end{align*} View SourceRight-click on figure for MathML and additional features.where\begin{align*} \gamma ^{(5)}\left ({{t}}\right )=& -\frac {z_{1}^{(5)}}{C_{0}}, \tag {40}\\ \xi ^{(5)}\left ({{t}}\right )=& \left [{{ \begin{array}{c} z_{1}^{(5)}-\frac {u^{(5)}}{z_{2}^{(5)}} \\ \alpha _{B,1}x^{(5)}(t)+\alpha _{B,0}-R_{B}z_{1}^{(5)}-z_{2}^{(5)} \end{array}}}\right ], \tag {41}\end{align*} View SourceRight-click on figure for MathML and additional features.x^{(5)}(t)\in \mathbb {R} is the State of Charge (SOC) of the battery [%], z^{(5)}(t)=[z_{1}^{(5)}(t);z_{2}^{(5)}(t)]^{\top }\in \mathbb {R}^{2} , z_{1}^{(5)}(t) [A] is the battery current, z_{2}^{(5)}(t) [V] expresses the battery output voltage, u^{(5)}(t) [W] is the requested power from the battery (determined by the secondary control level), a_{B,0} and a_{B,1} are constants, C_{0} [A\cdot h ] is the capacity of the battery, and R_{B} [\Omega ] denotes the resistance of the battery. Each battery comes equipped with a battery constraint module. The main goal of the constraint module is to provide a window [u^{(5)}_{min} \;\; u^{(5)}_{max}] for u^{(5)} to the secondary level, such that x^{(5)} and z^{(5)} are kept within their pre-described limits. Based on the work of [31] the following constraints are prescribed:\begin{align*} u^{(5)}_{max,V}=& \frac {\left ({{\alpha _{B,1}x^{(5)}(t)+\alpha _{B,0}}}\right ) \cdot z_{1,min}^{(5)} - \left ({{z_{1,min}^{(5)}}}\right )^{2}}{R_{B}} \tag {42}\\ u^{(5)}_{min,V}=& \frac {\left ({{z_{1,max}^{(5)}}}\right )^{2} - \left ({{\alpha _{B,1}x^{(5)}(t)+\alpha _{B,0}}}\right ) \cdot z_{1,max}^{(5)}}{R_{B}} \quad ~ \tag {43}\\ u^{(5)}_{max,SOC}=& \frac {x^{(5)} - x^{(5)}_{min}}{\Delta t} \cdot C_{0} \cdot \left ({{\alpha _{B,1}x^{(5)}(t)+\alpha _{B,0}}}\right ) \tag {44}\\ u^{(5)}_{min,V}=& \frac {x^{(5)} - x^{(5)}_{max}}{\Delta t} \cdot C_{0} \cdot \left ({{\alpha _{B,1}x^{(5)}(t)+\alpha _{B,0}}}\right ) \tag {45}\\ u^{(5)}_{min}=& \textit {max}\left ({{u^{(5)}_{min,V}, u^{(5)}_{min,SOC} }}\right ) \tag {46}\\ u^{(5)}_{max}=& \textit {min}\left ({{u^{(5)}_{max,V}, u^{(5)}_{max,SOC} }}\right ) \tag {47}\end{align*} View SourceRight-click on figure for MathML and additional features.where z_{1,min}^{(5)} , z_{1,max}^{(5)} , x^{(5)}_{min} , and x^{(5)}_{max} are the minimum and maximum bounds of the terminal voltage z_{1}^{(5)}(t) and the SOC x^{(5)}(t) of the battery, respectively, and are provided by the battery manufacturer. \Delta t is a discrete time step, which can be tuned to alter the power constraints related to the SOC of the battery. The hardware sensors that are used to monitor the operation of the battery are a terminal voltage sensor and a battery current sensor, while the state of charge is not measured (can only be estimated). Thus, the battery sensors are defined as follows:\begin{align*} \mathcal {S}^{(5)}~:~y^{(5)}(t)=\left [{{0\;1}}\right ]\cdot \left [{{\begin{array}{c} x^{(5)}(t) \\ z^{(5)}(t) \end{array}}}\right ]+d^{(5)}(t)+f^{(5)}(t),\, \tag {48}\end{align*} View SourceRight-click on figure for MathML and additional features.with d^{(5)}(t),\,f^{(5)}(t)\in \mathbb {R}^{2} . The model of battery 2~(\Sigma ^{(6)}) and its associated sensors are defined similarly.

SECTION F.

Simulation Parameters

The systems described in the above subsections are employed in this paper using the following parameters [22]:

Internal Combustion Engine k_{ICE}=3000\;m/s^{2} ; a_{1}^{ICE}=5.48\cdot 10^{-5}\;kg/GW^{3}h ; a_{2}^{ICE}=-0.206\;kg/MW^{3}h ; a_{3}^{ICE}=5.545\cdot 10^{-4}\;kgs^{2}/kWh ; a_{4}^{ICE}=-0.271\;kgs/kWh ; a_{5}^{ICE}=-3.55\cdot 10^{-5}\;kgs/MW^{2}h ; a_{6}^{ICE}=600\;kg/kWh ; P_{ICE}=1200\;kW .

Induction motor k_{ICE}=1000\;m/s^{2} ; R_{2}=0.01\;\Omega ; \eta _{I}M=0.95 ; P_{IM}^{max}=800\;kW .

Gearbox, shaft and propeller J_{tot}=12500\;kg\cdot m^{2} ; i_{ICE}=7.5 ; i_{IM}=24 ; \eta _{T}=0.95 ; C_{p}=670\;kg\cdot m^{2} .

Generator sets k_{GS}=4000\;m/s^{2} ; J_{GS}=4167\;kgm^{2} ; R_{GS,int}=0.15\;\Omega ; L_{GS}=0.0021\;H ; a_{G,1}=3.34\;s^{4}/kgm^{2} ; a_{G,0}=0.57\; As^{4}/kgm^{2} ; a_{1}^{GS}=5.55\cdot 10^{-4}\;kg/GW^{3}h ; a_{2}^{GS}=-0.58\;kg/MW^{2}h ; a_{3}^{GS}=2.15\cdot 10^{2}\;kg/kWh ; \eta _{GS}=0.95 ; P^{max}_{GS}=665\; kW ; P^{opt}_{GS}=524\;kW .

Batteries and Constraint modules SOC(0)=100\;\% ; a_{B,1}=111\;V ; a_{B,0}=389\;V ; R_{B}=0.0225\;\Omega ; \eta _{B}=0.97 ; SFOC_{ICE,nom}=72.1\; kg/kWh ; V_{grid}=3300\;V ; f_{grid}=50\;s^{-1} ; \eta _{FC}=0.99 .

References

References is not available for this document.