-The Shipboard Power System (SPS) is the element of a ship that is responsible for supplying energy to vessel operations. This component is critical to the survival and safety of the ship because many accidents may occur during ship navigation are often due to electrical failures. The SPS manages the electrical topology to successfully supply energy to the several onboard components. The proposed reconfiguration architecture uses a distributed and mission-oriented approach based on a generic-purpose self-adaptive middleware (MUSA). This paper illustrates how MUSA has been customized to dynamically reconfigure the electrical circuit of a vessel. In case of failures or unexpected events, it generates at run-time several possible solutions that properly considers ship's mission and the current scenario. The solution also includes a Matlab/Simulink simulator to validate the solution. Index Terms-Shipboard power system, SPS reconfiguration, selfadaptive system
I. INTRODUCTION
In recent years, the maritime sector is highlighting a high value of innovative and technological content (ICT), especially when faced with the need to respond to objectives such as safety, efficiency, and environmental impact. “EMSA’s annual overview of 2015 marine casualties and incidents” reports that most of the accidents mentioned are due to loss of control or damage to ships or equipment. The ship power production and distribution failures play a relevant role in such incident scenarios. The Shipboard Power System (SPS) is the component responsible for granting energy to navigation, communication, and operational systems. It is consists of various electric and electronic equipment, such as generators, cables, switchboards, circuit breakers, fuses, buses, and many kinds of loads.
Modern ICT technologies can nowadays automatically accomplish real-time data acquisition, classification, assimilation, and correlation at a reasonable cost. Software-based reconfiguration systems consist of two different layers: the software layer encapsulates the logic for the monitor and the control of the underlying electrical layer. In practice, the software system manages onboard switchboards and circuit-breakers, to direct the power flow where it is necessary for restoring a fault situation.
In [
In [
The present paper focuses on SPS reconfiguration in case of single
or multiple failures. This work starts from a detailed analysis [
This paper is organized as follows: Section II introduces the SPS domain and the reconfiguration problem; Section III illustrates the proposed solution architecture and algorithms. Section IV introduces a fault scenario that is used to demonstrate the adaptive ability of the system. Finally, some conclusions are drawn in Section V.
The SPS is the electrical and electronic hearth of a ship, it is composed of a set of components such as power generators, buses, circuit breakers, heterogeneous loads, and others electric subsystems appointed to navigation, communication and so on. In the last decades, some ships are equipped with direct-current (DC) because of the following advantages if compared to the alternate-current (AC): 1) smaller components and compact power converters; 2) easier connections; 3) no reactive power and harmonic issues; 4) faults reduction and easier reconfiguration procedures.
The main disadvantage of DC systems is that voltage shifts are more difficult to be realised than in AC systems where transformers do that with minimal losses.
Loads often are distributed in zones and fed power from the
main electric buses. It is usual to classify loads according to their
importance into vital and non-vital categories, where vital loads are
non-sheddable loads that directly affect the survivability of the ship,
while the non-vital ones may be shed in order to prevent a total loss
of ship’s electrical power, or for protection purposes. Moreover, the
loads can be categorised regarding QoS as un-interruptible, short-term
interrupt, and long-term interrupt [
Reconfiguration in an electrical SPS is a critical operation requested in unexpected situations such as in the case of severe or major faults. The reconfiguration procedure is driven by the ship power and energy management control, that communicates with all the generators and loads to keep the continuity of service during
MISSION 1: NAVIGATION Goal A [priority: normal] Goal B [priority: low] Goal C [priority: normal] Goal D [priority: normal] Goal E [priority: normal] Goal F [priority: high]
MISSION 2: IN HARBOUR Goal A [priority: high] Goal B [priority: low] Goal C [priority: normal] Goal D [priority: normal] Goal E [priority: high]
Goal F [priority: normal]
MISSION N: IN COMBACT Goal A [priority: low] Goal B [priority: low] Goal C [priority: high] Goal D [priority: normal] Goal E [priority: high]
Goal F [priority: low] reconfiguration operations. In this way, the reconfiguration of the electrical layer can isolate faults, restore/transfer power to vital loads, but also, more generally, it can optimise the management of electrical and electronic equipment to improve energy efficiency.
During normal navigation or after a specific event such as a weapon hit or a collision, there can be a series of multiple equipment damages. These can affect electrical layer and/or other systems such as the navigation one.
The strategy that enables restoration of the electrical power system
is called reconfiguration. The number of steps and the adopted
strategies (that can also involve humans) may vary. In particular,
in a recent work [
Smart reconfiguration methodologies need complex coordination
between electrical power and protective functions, and must deal
with several electrical architectures (radial, ring, zonal, . . . ). Very
frequently applied, zonal architectures are electrical configurations of
the SPS where loads are ideally divided into zones. Such architectures
are frequently used because they enable an easy sectioning of the ship
electric level thus preventing that a single minor fault may spread in a
systemic failure [
A. MUSA: A Middleware for User-driven Service Adaptation
The Middleware for User-driven Self-Adaptation (MUSA) has
arisen from a couple of pressing objectives in the research agenda
of dynamic workflow execution: managing run-time business process
evolution and adaptivity [
The key aspect is a clear separation of two points: ‘what the system has to address’ and ‘how it will operate for addressing it’. The enablers of this vision are i) representing what and how as run-time artifacts the system may reason on (respectively goals and capabilities); ii) a reasoning system for connecting capabilities to goals; iii) finally a common grounding semantic, represented with some formalism.
The first aspect of MUSA is the ability to work with run-time
requirements as a set of goals to be injected into the system [
MUSA tries to address the goals by finding suitable solutions
using the concept of Capabilities as first-class entities for agent
deliberation [
Consequently, self-adaptation is defined as a space search problem.
The algorithm used in [
The agent-based, hierarchical and distributed nature of MUSA allows for managing multi-layer services as a single service, thus hiding the complexity of service composition. Moreover, agents are suitable for granting adaptation because they may change without affecting the whole structure.
SPS reconfiguration problem embraces a series of possible scenarios, goals, and decisions based on functional and non-functional requirements. Functional requirements include prescriptive goals – related to onboard operations that must be granted without any degree of freedom – and soft goals which also can be satisfied partially, thus granting a minimal degree of functionality. The adoption of goals allows a seamless description of the expected behavior in terms of loads that must be powered.
Moreover, requirements in a vessel are not static: they change according to the operative context. Indeed, the operating scenario may change, and a series of reconfiguration sub-goals may be necessary to comply with specific requirements of the electrical layer. Some particular constraints are, for instance: providing energy to vital loads, protecting loads with different priorities, shedding non-damaged loads that may not be powered (possibles causes: insufficient electric power, no energy transportation route to that load). These sub-goals may strongly vary according to the kind of vessel (a warship vs. a cargo), the type of mission (approaching the harbor, offshore navigation, combat actions), and the current amount of power produced by generators and energy storage devices. The system must be flexible enough to switch its goals at run-time, for example when the ship’s mission change.
To this aim, we introduce the concept of Mission. A mission is a description of the relation between the operating context and the degree of priority to be assigned to the system goals.
The solution we propose is based on a dynamic description of the vessel’s missions. An example is shown in Figure 1. When the system power is under the value required for feeding all the vessel’s MATLAB conceptual solutions loads, the SPS reconfiguration must consider not all the goals are equally important to be pursued. Indeed, some loads are mandatory for the vessel survivability [vital loads] while other ones are also important but not necessary [semi-vital loads]. Finally, other loads may be switched off without affecting ship mission accomplishing [non-vital loads]. Consequently, goals may be classified by different priority depending on the specific context. Thus, the reconfiguration system will always prefer to address a higher priority goal.
The architecture of the solution is based on the integration of MUSA and Matlab, as shown in Figure 2. MUSA provides a highlevel reasoning infrastructure that is triggered when the monitoring sub-system discovers the standard electrical configuration is affected by a set of failures.
In this process, MUSA makes a very limited use of physical values to elaborate the solutions. It calculates the available amount of power, and it penalizes configurations in which loads use more power than the available one. The role of Matlab becomes fundamental because it allows grounding the conceptual solution by employing Simulink to simulate physical parameters such as the effective current measured at the generators poles, identifying extra-voltage or unstable situations that a symbolic reasoning is not able to evaluate. The outcome of Matlab is to discard unfeasible solutions and to sort the remaining ones according to their quality.
Most of the modern approach to self-adaptation puts the feedback
loop as the core of the architecture. The proposed solution adopts
one of the most common models for realizing the feedback loop: the
MAPE-K [
The Monitor Module. The vessel is instrumented with a set of sensors for monitoring some physical variables. The monitor module shall control these sensors to collect raw data with the aim of detecting possible failures.
The Analysis Module. The system should be able of reasoning on raw data to estimate all the relevant vessel conditions (e.g., steady state, electrical failure, etc.) thus obtaining the necessary information to characterize and assess system performance fully. For instance, the analysis should infer the kind and the position of possible electrical failures when they occur.
The Planning. component is responsible for deciding the kind of recovery to enact. The Proactive Means-end Reasoning Module elaborates a configuration for maximizing the continuity-of-service of vital loads during the reconfiguration operations, avoiding instability or even system collapse. According to the current mission and the kind of maneuver, loads are dynamically dealt according to the three categories (vital, semi-vital and non-vital). The contribution of Matlab/Simulink allows selecting feasible solutions via simulation. The design of this module incorporates human factor to enable specialized operators (mainly the captain) to maintain situational awareness and take appropriate measures during normal and emergency conditions.
Execute. The main operations of the SPS reconfiguration are connection/disconnection of the loads and the generators. These actions are performed by controlling the automatic switches placed on electrical buses. Controller distribution and autonomy are fundamental features to allow each block may act independently from the rest of the system.
The whole adaptation cycle is summarized in Figure 2. The ship captain selects the current mission of the vessel. The mission classifies the loads according to a typology (vital, semi-vital and nonvital) and finally, each of the loads is associated with a priority.
A monitoring module supervises the vessel’s status and raises a new adaptation need when it discovers a failure scenario. In this case, MUSA receives the current state of the vessel, and it explores a space of solution driven by the mission’s goals and it produces a list of conceptual solutions. These are ‘conceptual’ because the main MUSA algorithm works on a conceptual description of the electrical topology where some implementation aspects are missing. It is up to the Matlab simulation to validate these solutions by verifying their feasibility in terms of physical aspects. Therefore, only feasible solutions will be presented to the vessel’s captain.
The cycle concludes when the captain selects and makes operative the solution he prefers thus enabling the control sub-system to enact the solution in the real electrical circuit concretely.
The next section explains a reconfiguration scenario due to a set of failures. It illustrates, in details, how the architecture takes care of the failure conditions and it is able of generating a reconfiguration plan to lead the general state of the vessel toward a safe condition.
In this section, we propose a case study inspired by [
The proposed electrical model comprises seven DC load zones that are powered by two primary generators (MG) and two auxiliary generators (AUXG). Each MG provides up to 6 MW while each AUXG provides up to 2 MW. It is assumed that nonvital loads can be shed to grant the power to the vital and semi-vital loads in case of emergencies.
To demonstrate the results provided by the proposed system, we
will study a multiple-failures scenario inspired by [
The fault scenario (failures FS1+FS2+FS3 in Figure 4) occurs when multiple interruptions happen on the starboard bus. As a consequence of these multiple failures, loads L1, L5, L9 are no more powered. This has a serious impact on mission accomplishing since load L9 is a vital one. Loads L15, L18, L21, L24 are still unpowered because of the initial mission configuration.
The reconfiguration procedure performed by MUSA proposes several solutions. They respect the constraint coming from the maximum amount of available power (also considering auxiliary generators if switched on during the procedure). However, the MUSA module is not aware of the real behavior of the system at the most detailed level, including currents in each node, currents delivered to loads and
F4
Aux SW G1 AUXG1 c1 x x x x x x x c2 x
SW5 SW P2 SW6 SW7 SW S2 SW8 c3 x x x x x x x x L5 L6 L7 L8 c4 x
SW1 SW P1 SW2
SW3 SW S1
SW3
L1 L2 L3
L4 Type Priority Load
config initial state fault cond SW9 SW S3
L9 x x x x x x x x x x x x x x x 14 16 21 25 30 32 37 41 46 non-powered loads
L5 L5
L5
L5-L24
L5-L21-L24
L5-L18-L21-L24
L5-L15-L18-L21-L24
L1-L5-L15-L18-L21-L24
Legend: config is the number of solution discovered by MUSA; c1-c8 are the subset of all the capabilities used in this example (c1=switch ON aux1 generator cap, c2= switch ON aux2 generator cap, c3=open switch swp3 close switch sws3 cap, c4=open switch sw 5 cap, c5=close switch sw 15 cap, c6=close switch sw 18 cap, c7=close switch sw 21 cap, c8=close switch sw 24 cap); gen state is the state of the four generators (main1, main2, aux1, aux2); load state is the state of the loads according priorities (see Table I); score is the result of the score heuristic.
Legend: config is the number of solution discovered by MUSA; overloads are situations which the current at the ports of a generator is higher than a threshold; not powered loads are loads that are not supplied; wrongly non-powered are loads that could be supplied with energy but the configuration misses to do; underused gen are generators that are used below their possibility; redundant cap indicates the solution contains capabilities that could be removed because their effect is null; solution size is the number of capabilities that are used in the solution.
SW1 n L1 SW P1
SW2 v L2 SW3 s
L3 n L4 SW S1
SW3 14
Port Bus 4 currents dispatched by generators (that being real have a maximum amount of power they can provide). Indeed, the MUSA module operates at a symbolic level of abstraction. It computes which paths are enabled for current passing once a specific configuration of switches is selected and what total amount of current is demanded to generators by the current-reachable loads. By using Matlab/Simulink, our system simulates all the provided reconfiguration procedures and it removes those who violate physical specifications of the real system (for instance maximum amount of power for each generator). Results are reported in Table II. The first two rows of the table report the initial operating conditions selected by the captain according to the mission profile (see also I). It is worth to note that, although no faults are active, some loads are not powered (L15-L18-L21-L24).
This descends from the limited power of the two main generators (not sufficient to power all the loads of the vessel) and the nonvital role of some loads for the mission. The quality of service (score) for this configuration is 4’194’288. After the three faults (Figure 4), the quality of service drops down to 2’620’784. This happens because loads L1-L5-L6-L9-L15-L18-L21-L24 are no more powered as a consequence of the faults. This is the initial condition the proposed reconfiguration approach has to cope with. The configurations generator proposes 8 different solutions to the problem as reported in Table II. Each configuration employs a different set of capabilities. As we can see looking at the score column, the first three proposed configurations achieve the same score result but they use a different set (and number) of capabilities to do that. Oddly, configuration 1 activates the auxiliary generator AUX2 without any evident advantage with regards to the following two configurations.
Configuration 2 proposes to open switch sw5 (controlling load L5) but since this is not reachable anyway, the action has no effect on the result. From configuration 4 to 8, a growing number of loads is disconnected from power, this causes a decrease in the quality of service coming with a diminishing need for power (configuration 8 does not even need auxiliary generator AUX1) and the number of employed capabilities.
In order to better illustrate the proposed approach, we will study two configurations. The first one (configuration n.1 from Table II) prescribes the following operations: cap: switch_ON_aux1_generator_cap cap: close_switch_sw_15_cap cap: close_switch_sw_18_cap cap: close_switch_sw_21_cap cap: close_switch_sw_24_cap cap: switch_ON_aux2_generator_cap cap: open_switch_swp3_close_switch_sws3_cap
The first step consists in switching on the generator AUXG1, then loads L15, L18, L21, and L24 are powered, the generator AUXG2 is switched on, and, finally, the transversal bus 3 configuration is changed (by opening switch SWP3 and closing SWS3). The reader will note that the prescribed operations do not follow a precise or logical order (for instance the two auxiliary generators are not switched on together). This is an obvious consequence of the configurations generator algorithm for solution space (WTS, see Figure 1) exploration and of the simplification implied by not studying transitory intermediate configuration states. The reconfiguration solution is supposed to be entirely applied at the same time (not a big issue when working in DC although some aspects will be further studied in the future).
The second reconfiguration solution we will study configuration n. 4 from Table II) prescribes the following operations: cap: switch_ON_aux1_generator_cap cap: close_switch_sw_15_cap cap: close_switch_sw_18_cap cap: close_switch_sw_21_cap cap: open_switch_swp3_close_switch_sws3_cap
The procedure switches on auxiliary generator 1, together with loads L15,L18,L21. The configuration of transversal bus 3 is reversed as in the previous configuration.
Differences between these two configurations become evident after their simulation with the Matlab module. The overall results of the Matlab simulations are reported in Table III). This summarizes the most relevant problems that can be found by using a physical-level simulation of the circuit. The first column reports the number of configurations, the second column reports the overloaded generators (if any). The first three configurations overload the generator MG1 thus becoming unacceptable (see the last column of the table, column ’feasible’). This condition may not be discovered at the symbolic level, since it only performs a global balance of power (demanded power vs available power). In reality, it may happen that power required to the available generators is not equally distributed and one of them may overload while the other remains well under its working limits. The third column lists loads that are not powered in the proposed configuration. This is directly linked to the quality of service score (from the previous table). Solutions with better scores are to be preferred if they satisfy the goal requirements (all vital loads are powered). The fourth column reports the list of loads that could be powered according to the circuit configuration, but they are switched off by the wrong use of a capability.
Column ’underused gen’ lists the generators that are switched on by the proposed configuration but their power is not effectively used according to the Matlab simulation (in other words they do not really provide any power). Again, this happens in scenario 2.
Column ’redundant cap’ lists the capabilities (better their scope) that are employed in the configuration but do not provide any effect (for instance the already discussed use of c4 in configuration 2). Column ’solution size’ reports the number of employed capabilities. This is a sensitive metrics since we prefer shorter (and therefore intuitively simpler) solutions when they achieve the same score. Finally, column ’feasible’ summarizes the previous results and it marks as acceptable solutions that do not violate physical limits of the circuit behavior (such as generator overloads).
Going back to the previously studied configurations n.1 and n.4, we can see that the Matlab simulation of the proposed solution n.1 reports that one generator (MG1) is overloaded and one load (L5) is not powered. This solution is therefore not feasible. Conversely, the simulation of configuration n.4 proves it abides the limits imposed by the electrical components, and it is therefore feasible. In this configuration, loads L5 and L24 are not powered but they are listed as non-vital in this mission; therefore this is not a problem. The two cases show the importance to clean the solutions provided by the configurations generator with the simulations done by a module that is well aware of the behavior of the physical layer of the system (Matlab in our case). Considering the results proposed in Table III, we can see that the best solution is configuration n.4 that achieves a score of 4’194’174 and requires five capabilities. Following solutions (n.5-6-7-8), although feasible, achieve a lower score (in fact fewer loads are powered by these solutions) but also use a smaller number of capabilities, therefore may be useful in a real scenario when something could go wrong in applying the preferred solution n. 4.
This example shows the ability of responding to unexpected situations by proposing more than one reconfiguration solutions. It is worth to note that the proposed system could easily automatically identify and enact the best solution but we decided not to implement that because in real scenarios, the final responsibility for the adoption of a reconfiguration strategy should always be on the person in charge.
This paper presented an adaptive architecture for dealing with the reconfiguration of Shipboard Power Systems (SPSs) that is the component responsible for supplying energy to various services of a vessel. The solution adopts MUSA as the base for the reconfiguration system and Matlab for enriching the system of a physical simulator.
We have extended the main concepts of MUSA by introducing the new concept of Mission, a dynamic container of goals, associated with their priorities. We finally proposed a case study in which we discuss a failure scenario, and we illustrated how the system behaves in critical circumstances.