How to link ship architecture and maritime operations
It is a challenge for ship designers to integrate the ship end users´ knowledge and experience of maritime operations. The OPeration–ARchitecture (OPAR) model lays out a framework that helps to bring maritime operations naturally into the ship design process.
The gap between the architecture and the operation of the ship
Across stakeholder groups involved in the ship design process such as designers (ship designers, sub-contractors, ship yards) and the end users of the ship (ship owners, ship managers and operators, the ship’s crew), the involved stakeholders have different levels and directions of expertise. Consequently, frameworks for understanding the separate parts of ship design can be hard to share across disciplinary gaps. This is especially important for the gap between the technical expertise of the ship designers and the operational experience of the end users. Ship designers are traditionally focusing on the ship and the ship systems from a technological perspective that does not necessarily includes a human-centred perspective that focuses upon how ship crew actually use the ship and the systems designed for them.
The gap between design and operation is a serious challenge, since miscommunications and non-inclusive design processes can lead to sub- optimal or even unsafe ship design solutions. Designers need to understand the tasks of the human operators during ship operations and use this understanding to create designs that are compatible with all the systems the ship users interact with.
To help bridge the gap between maritime operations and naval architecture, we have developed a framework in which design activities that combine a technology-centred perspective on ship systems and a human-centred perspective on the use of ship systems can take place. We call this the OPeration-ARchitecture, or OPAR framework, where ship design is modelled as a concurrent exploration of the operation of the ship (how the ship is used) together with the architecture of the ship (what the ship is made of).
Reframing ship operation and architecture, and the design activities used to generate them
We model the ship’s operations as the combination of work tasks carried out by the ship’s crew when engaged in the operation of the ship. We model the ship’s architecture as the combination of the systems that make up the ship. OPAR places the human-centred representation of the ship operations next to the technology-centred representation of the ship, and proposes design activities that connect these two representations. Because ship design is iterative, OPAR also includes design activities related to the generation and evaluation of concepts.
Similarly to starting a design process by looking at existing ships, we recommend starting the design process by undertaking a field study on a ship to map the working and living conditions of the end users of the ship, as well as how they are currently performing ship operations. Using these field insights, we then recommend analysing how the existing systems on board the ship enable its human operators to use the ship and identifying design problems that might impact the safety and efficiency of ship operations. From this analysis, we recommend sketching what architectural solutions might enable the human operators to perform their work in better conditions.
In addition, OPAR can be used in other use cases such as:
- Retrofitting new systems, to check if the new systems require a change in their operational procedures. Conversely, the designer can start with the analysis of an operation and use it to select a specific system that allows the operation to be performed in a better way.
- Repurposing of the ship, to check how different operations can be implemented using the existing ship architecture, or if the architecture needs to be modified to perform the desired new operation.
- Designing remote-controlled/autonomous ships, because in this case both operations and architecture can be partially unknown. In addition, the operation of the ship might not be spatially constrained to the ship, with ship control centres being placed ashore. In the case of automated systems from which humans are progressively being removed, there needs to be an analysis of what human operators do and how they do it, in order to derive what can be automated, and how.
-
Connecting more than architecture and operation
We designed OPAR so that it can enable several types of connections in the design process:
- Connecting design process steps such as early concept design and detailed engineering.
- Connecting design activities, for instance human- or technology- centred design activities, and design activities that take place ashore with activities that take place at sea.
- Connecting design data, for instance human-centred, qualitative design data with technology-centred, quantitative design data.
- Connecting users of the ship design process, for instance ship designers and ship end users, through the capture of end users experiences when operating a ship.
The way in which the design activities are combined when using the OPAR framework does not need to be predefined. More loose processes can be used, going back and forth between initial and preferred situations, in the dimensions of operation and architecture. Analysing published material in the ship design research literature, we have observed that design methods that relate to the design of the architecture of a ship are predominantly used. This type of approach can be represented in OPAR by a vertical loop that iterates within the dimension of ship architecture, without going into the dimension of operation. The use of OPAR introduces an additional dimension to ship design that is complementary with existing ship design processes and methods. This dimension also opens for the possibility to work with prototyping ships from an operational perspective, for example using scenario mapping techniques.
In terms of design theory, the flexibility of OPAR helps to implement what some authors (for instance Willemien Visser in her book The Cognitive Artifacts of Designing) refer to as the opportunistic organisation of design processes. Visser observed that “Designers proceed in a non-systematic, multidirectional way. . . . The basis for such organisation is designers taking into consideration the data that they have at the time: specifically, the state of their design in progress, their representation of this design, the information at their disposal, and their knowledge”. In practical terms, using OPAR helps each participant in the design process entering the design space with their own perspective, before combining it with the perspective of the other participants. It also enables them as a team to assess what they need to know to be able to proceed, or who else they might need to work with. It can also be used to introduce or to create new design methods that help generate connections across the two axes of the framework.
Improving the design experience, repertoire, judgement and process
We believe that using OPAR has the potential to open up new perspectives on the design process. We observed that designers who worked with ship workplaces and end user experiences were triggered to think about their own experience as designers and how their work might impact the experiences of the end users. The potential impact on the ship design process is double. First, it can lead to better including the operational experiences of ship end users as design material in the design process. Second, the focus of ship designers on the end user experiences as well as their own can lead to improve the design process by augmenting the design repertoire of the ship designers, and tuning their design judgement towards design decisions that better prioritise what the ship architecture needs in order to enable an optimal operation of the ship.
Further reading: Journal article “Connecting Ship Operation and Architecture in Ship Design Processes”
The project is done in collaboration with Ulstein International, Pon Power and DNV GL and funded by the Norwegian Research Council in the MAROFF program. Project number: 269494