1 Background

Increasing introduction of advanced technologies into control rooms may improve effectiveness and efficiency, but it could also bring significant challenge to the operators in supervisory tasks (Ivergård and Hunt 2009; Landauer 1995; Sheridan 2016). While the challenges exist in other domains, this paper focuses on the engine control room (ECR) onboard ships. A systematic research for the relevant literature regarding the issues of ECR did not produce much published work in the area. Databases including Scopus, Web of Science, and Google Scholar were used to search for the following combinations of keyword strings: “human factor,” “engine control room,” and “ship” located within the title/abstract/keywords (Scopus) or topic (Web of Science and Google Scholar) for the time period limited from 1990 to 2018 in Scopus and Web of Science. The numbers of papers retrieved from these databases were 17, 2, and 50 (first 5 pages in Google Scholar) respectively. The inclusion criteria assessed whether the papers had an exclusive concern about the work performed in the ECR and the main emphasis on human factor issues associated with introduction of new technologies. In addition to these three databases, we also searched the string of “engine control room human factors” by using the Chalmers University’s library service and checked the first 20-retrieved recommended papers to see if there were any reports that were not indexed by the other databases. After a close scrutiny of these results, the included relevant research papers are from a few researchers like Lundh, Mallam, Wagner, and Lützhöft (Andersson and Lützhöft 2007; Grundevik et al. 2009; Lundh et al. 2011; Mallam and Lundh 2013, 2014, 2016; Wagner et al. 2008). The search results provide a very important research foundation for this conceptual paper but they also suggest that there is a scarcity of such work in maritime research regarding the ECR. This conceptual paper is also based on the experience of a research group which includes former ship engineers from a Swedish fleet. This section presents an overview of the issues.

1.1 Engine control room in the engine department

The main constituent of a modern ship engine department is the engine room (ER), which contains various indispensable and also complex equipment and systems for ship propulsion, power generation, and other necessary operations, such as main engines, auxiliary engines, cooling water system, lubricating oil system, fuel system, compressed air systems, drinking water systems, sewage system, bilge system, ballast system, and boiler and firefighting systems. (van Dokkum 2013). The ECR is very important to the engine department as the information hub. The automation monitoring, problem diagnosis, and maintenance of these systems require dedicated engine officers and operational personnel to perform various supervisory and engineering hands-on tasks in the ECR (van Dokkum 2013).

Parker et al. (2002) claimed what shapes the maritime industry from other industries is that much more stress and pressure from seafarers have been reported than other work group work. From the operational perspective, the safety and efficiency depend upon a coherent set of control centers, which suggests the importance of the control room design (Lützhöft and Lundh 2009; Stanton et al. 2010). One big difference between the bridge and ECR is that that bridge is manned all the time while the ECR could be unmanned most of the time on modern ships, except some merchant, passenger ships (van Dokkum 2013). The actual work situation in ECRs is rather demanding: previous studies have explored this confined space from different perspectives, including task demands, interaction with various information systems, workload, working hours, and physical environment (the extent to expose workers to hazardous substances and situations for an enduring period, e.g., confined space, air temperature and humidity, noise, vibrations) as well as organizational factors such as hierarchical organizational structure and authoritarian leadership (Lundh et al. 2011; Lundh and Rydstedt 2016; Orosa and Oliveira 2010; Stanton et al. 2010; Wagner et al. 2008). When a critical alarm is set off, the engineers have to present themselves to the ECR and quickly develop situation awareness (Endsley 2011; van Dokkum 2013). Work pressure, fatigue, environmental factors, and long periods of time away from home contribute to the psychosocial stresses (Hetherington et al. 2006). High degrees of fatigue and stress reduce awareness, productivity, and lead to higher risk of making mistakes (Håvold 2015; Trakada et al. 2007). What makes it even more error prone is that there are full of displays and controls, a plethora of analogous and digital systems in the ECR (see Fig. 1). In general, heterogeneous and distributed resources and tools reveal the intrinsic complexity in the ECR.

Fig. 1
figure 1

An ECR in a large modern cruise ship

Full size image

1.2 The realities within the dynamic social-technical system

Fast advancing technologies have become a significant force in the workplace but “disruptive technologies” can result in significant impact (Bower and Christensen 1995). While the goal of maritime shipping remains to be transporting goods in a safe, productive, and efficient way (Stopford 2009), there are considerable changes in the work content and demands mainly due to rapid development in technology (Lundh and Rydstedt 2016): In recent years, manufacturers and service providers in the shipping domain have been constantly implementing digitalization and computerization to encapsulate and transfer the analog world to the digitalized world where the manipulated target becomes intangible software. Digital supervisory systems with more artificial intelligence and quicker responsiveness have been introduced to replace analogous equipment; new types of tasks in monitoring and controlling have been emerged for the ECR operators; all these changes contribute to the reduction in the number of crew member meanwhile bring significant increase of workload for the remaining crew without influencing much in hierarchical organizational structure (Lundh and Rydstedt 2016; Mallam and Lundh 2013; Mårtensson 2006; Wagner et al. 2008).

One prominent challenge of digitalization is information fragmentation (Lundh et al. 2011; Wagner et al. 2008)—the information is unprecedentedly distributed and scattered on different vendor-specific monitoring devices and equipment considering the types of services and size of governed data, waiting to be found, clicked, read, memorized, compared, and analyzed by a human operator. The operators today must spend more time remotely monitoring critical systems in ER with various digital screens and displays (Lundh et al. 2011).Wagner et al. (2008) suggested that the fragmented digital information structure used for system control can increase vulnerability and operational risks at critical moments in the ECR. Lundh et al. (2011) found that the operators can feel that they were drowned in the dispersed information and there is a strong need to have an “information overview.” Much research has also addressed the similar problems of the cognitive overload that could hinder the human agent from noticing the environment change and filtering out the needed information (Kahneman 1973; Navon 1985). Automation usually functions rather well in routine tasks but it would be of least assistance when the workload becomes high in dealing with contingencies. That is the “irony of automation” (Bainbridge 1983). The ECR has a predisposition of “irony of automation”: an ECR could be unmanned most of the time, but if something unexpected occurred then the workload could become high very quickly. The engineers would basically depend on their knowledge and experience to identify the problem, interpret the alarms, and search required information in order to solve the problem. Technology is great when it works (Lützhöft 2004). When it does not, human errors might occur if there is any misinterpretation. For example, House and Place (2006)‘s report on the investigation of Savannah Express ship accident concluded that the engineers failed to realize the “indicated tacho faults were not the root cause of the engine failure” (p. 47) and misinterpreted the relationship between the tacho alarms and the hydraulic pressure alarms due to their insufficient understanding of the engine systems.

Human errors, or the problems of human fallibility (Reason 2000), are frequently subject to individual factors, e.g., insufficient understanding in the case of Savanah Express (House and Place 2006), instead of the system factors (Hancock 2013; Mosier et al. 2001; Norman 1990; Skitka et al. 1999, 2000), e.g., the context in which the operators work. The system factors are related to physical, social, and organizational aspects (Lundh and Rydstedt 2016; Viktorelius 2017). Human errors cannot be totally eradicated (Foord and Gulland 2006; Rasmussen et al. 1994) and we need to recognize the limitation of training (Chavaillaz et al. 2016; Lundh et al. 2015; Sauer et al. 2015). Physical, cognitive, and organizational ergonomics are all very important to the sociotechnical systems, and this paper mainly looks at the issues in the ECR from the eco-system’s perspectives. Constant emergence of novel information technology (IT) solutions, state-of-the-art technological artifacts, and advanced gadgets (Gentzsch et al. 2016; Gubbi et al. 2013; Heilig and Voß 2016; Koga 2015; Lukas 2010; Man et al. 2017) that aim to provide decision support paradoxically places more demands on the practitioners (Lundh and Rydstedt 2016).

Here, we will re-examine a case in an ECR to illustrate how various display units and ubiquitous interfaces onboard, expanding in numbers, functions, and complexity, are influencing the engineers working performance. Wagner et al. (2008) conducted a link analysis in an ECR to illustrate how an operator needs to take care of the various signals and conduct manual tasks at different nodes (see Fig. 2).

Fig. 2
figure 2

A link analysis in a modern engine control room (Wagner et al. 2008)

Full size image

The top drawing in Fig. 2 has used numbers to denote two outstanding places that the operator frequently needs to be, “1” for the engine alarm information display area (also managing of the engine room equipment, start-up and shutdown, opening and closing valves, etc.) and “2” for the administration area. Their actual appearances are presented in the bottom of the figure. The link analysis points out the inconsistencies in placing of instrumentation pertaining to physical ergonomics (Lundh et al. 2011).

Wagner et al. (2008) found inconsistent issues in the alarm displays in the console. Figure 3 presents the console of the alarm management system in the ECR with its main alarm display at item 2. It also illustrates some other alarm displays pertaining to other sub-systems distributed over the control console, which may or may not integrated into the main alarm management system. For example, the displays of the cooling system to monitor the temperature and pressure of the pumps and other equipment have been integrated into the main control console. But the fuel oil purifier to clean the medium of impurities and the ventilation system may have their own specific control panels and designated displays; much information is not always visible or consistent in a main alarm display; the presentations of various alarm indications could be ambiguous and confusing (Lundh et al. 2011; Wagner et al. 2008).

Fig. 3
figure 3

Alarms can be distributed over a control console in the ECR (Wagner et al. 2008)

Full size image

In this shown case, there is no cross-platform overview with high consistency, accessibility, readability, and discoverability. The distributed systems were wired in a way that synergy of information integration and optimization is barely obvious. Such design might bring cognitive challenges that can undermine the engineer’s performance. This is a good example of how conventional platform-dependent, device-dependent, and vendor-specific tech-development view could be clumsy without proper considerations on the infrastructure. Original analogous systems have their advantages to allow rapid information access and overview, and these should be well considered in the digitalization process. What the control room most needs today is probably not another digital service or function but a strategy to govern the information in order to truly support information processing and decision-making.

1.3 Stagnant design methodology

Confronted with an evolving maritime sociotechnical system, the system design methodology in the shipping domain does not seem to advance with time to accommodate the contextual change (Man et al. 2019). Recent research points out that design work usually lacks a profound understanding of the type of work that is performed in the ECR (Lundh 2014). In a sociotechnical system, work as done usually differs from work as imagined (Hollnagel 2012). Although the necessity of considering human factors in marine applications has been there for over four decades (Lützhöft and Lundh 2009), the underlying technology-centric design approach remains to be dominant in the industry. It requires the human operators to adapt their performance and behaviors to the computer interfaces instead of considering how the actual working processes and operations have changed and adapted in reality (Allen 2009).

In recent years, human-centered design methods (ISO 2010) have been heavily developed and promoted in the human factor communities (Abras et al. 2004; Endsley 2011; Maguire 2001). While there have been efforts to incorporate the approach in engineering projects, they are primarily aiming at improving a standalone product’s usefulness and usability without necessarily enhancing the overall system performance (Mao et al. 2001). A fallacy of human-centered design is to “give users what they want” (Endsley 2011). As a consequence of the technological wave, various digitalization solutions have been proposed to patch individual problems or needs. Technological solutions have been introduced like placing “new cards” on top of a deck of “old cards,” making the working environment increasingly complex. For instance, the authors’ previous ship studies (Man et al. 2018) on a merchant vessel found that ad hoc screens and displays had been constantly mounted in the ECR to address the engineers’ needs of being aware of the navigational situations (see Fig. 4).

Fig. 4
figure 4

New screens and displays are constantly added to the ECR to meet a certain need

Full size image

A vendor’s IT solution might be efficient to address these concerns, but it is fundamentally restrained in this complex eco-system. Within the ECR, there are several work zones where a number of tasks or functions are performed (Wagner et al. 2008), such as the administrative area, normal monitoring area, and critical situation monitoring area. The development of the IT service used in these areas relies on different manufacturers and vendors and it is largely technology and device dependent, which inherently creates many technical barriers to develop the desired “information overview.” In addition, the introduction of new solutions can generate new “technology integration” problems (Wagner et al. 2008). Therefore, new solutions are needed to solve the induced problem. The “cheapest” solution, figured out by the adaptive users, could be attaching sticky note to the monitors, as it shows in Fig. 4.

For the industry, the design methodology is rarely aiming at the eco-system in the ECR. To keep “adding cards” or focusing on in-house development seems to be a dominant approach towards maritime digitalization. The situation is also subject to the contemporary business models in the maritime domain where related stakeholders are usually concerned about their own products, service design, and development. For service providers and manufacturers, they sell off-the-shell products and services to provide solutions; for service consumers, they buy another “card” to place it among the other IT “cards.” Without an open and holistic infrastructure conforming to certain standards to exchange information oriented for service design and development, the information optimization/integration and harmonization of emerging technologies at whole engine department’s level could be far-fetched. There is an increasing need to address the growing disparity between the design philosophies (i.e., fragmented design solutions and de-emphasis of the overall context) and emerging unruly technologies in the ECR.

1.4 Missing standards and regulatory support

In safety-critical industries, standards and mandatory regulations may address the design issues. There is a plethora of general control room design knowledge pertaining to information management and human element that may be applied to the ECR. For example, in the nuclear or the offshore industries, the International Organization for Standardization (ISO) Standard 11064-5 (ISO 2008) and/or International Electrotechnical Commission (IEC) Standard 964 (IEC 1989) have been implemented to provide principles, requirements, and guidelines to support information presentation and human machine interactions in design of control rooms. One instance is that ISO 11064 standard, as a process-oriented standard (Aas and Skramstad 2010), has been used for design of the control room for the Norwegian petroleum industry (PSA 2002). Its use in different phases of design (analysis, design, verification, etc.) in the offshore industry has contributed to safe operations (such as minimizing the human errors by employing the human-centered design approach or minimizing loss by intervene the accident path with technical safety functions) (Kjellén 2007) as well as improved working conditions (Aas and Skramstad 2010). However, large variations in the use of the standard have also been observed, which suggests the need for further application adaption and scope discussion (Aas and Skramstad 2010).

In the maritime domain, there is also an intricate system to stipulate safety-oriented rules and standards in terms of ship construction and operations (Lundh 2010; Mallam 2014). The overall situation is that although technologies have been constantly introduced to the ECR, the regulations to manage technologies and resources in their working environment are much lagging behind. Existing maritime regulations give little support to address the issues stated in previous sections in the ECR that concerns about growing presence of IT from information integration and optimization’s perspective. The majority of the established guidelines, rules, and regulations, general or specific, are not used in the ECR (Mallam and Lundh 2013; Wagner et al. 2008). The mandatory regulations of IMO International Convention for the Safety of Life at Sea (SOLAS) Chapter II-1 “Construction - Subdivision and Stability, Machinery and Electrical Installations” (IMO 2009) highlights the technical specifications for equipment installations while the non-mandatory SOLAS amendments (IMO 1998) only focus on the environmental factors and occupational risks in the ER. There is a lack of regulatory support from the International Maritime Organization (IMO), shipping’s highest regulatory body, concerning ECR design and operations, e.g., the considerations for information overview (Mallam and Lundh 2013).

With the ECR becoming an increasingly important role as an information center to the engine department, it is certainly necessary to set up clear goal-based standards but current regulatory statements are equivocal and ambiguous (Mallam and Lundh 2013). They have placed little concerns on the “soft” aspects like configurations between human and technology, the system hierarchical considerations facilitating information processing and understanding, and the inevitable space between work as imaged and work as done. The incumbent goal-based regulations are limited to provide “responsive” strategic road maps that are needed on a global scale to cope with the complexities residing in the emerging technological implementations and disruptive innovations. Mallam and Lundh (2013) suggested that this shows an “overall lack of cohesiveness, organization and initiative” (p. 524), revealing the regulatory incapability to govern the increasing technological development activities for human operators.

The vacuum space in the regulations (the lack of mandatory regulatory efforts about governing information in an integrated system) leaves much to those manufacturers and service providers to interpret by their own and partially result in the disparate but intertwined eco-system in contemporary ECRs. Though there are some standards developed by organizations with input from manufacturers, such as the Industry Standard on Software Maintenance of Shipboard Equipment recently developed by Comité International Radio-Maritime (CIRM) and Baltic and International Maritime Council (BIMCO) (CIRM/BIMCO 2017), they are not mandatory or they do not necessarily concern about interoperability from the perspective of the eco-system’s development in the wave of digitalization. Many manufacturers and service providers, particularly start-ups, are still largely developing their own standards for their own standalone products. What they would normally prioritize is their own business and technological innovation. One consequence is the gradual change of the overall context in which technological services are ubiquitous but there are “invisible walls” which prevent information from being optimized or integrated into an “overview” to inform the machines’ status. As Lundh et al. (2011) described in their study, what the engineers have in their workplace today is only “feedback merely as a change in digital numbers and/or a change in colour on a graphic symbol on a screen” (p. 389).

1.5 Summary

Section 1 has presented the background of ECRs and described various issues in the context of emerging technologies. Heterogeneous products and services may be built or owned by different vendors, manufacturers, and service providers, who may have fundamentally different strategies in developing their own technology trees, in-house technical standards, and implementation approaches (e.g., different programming languages, paradigms, middleware, and platforms). These stakeholders are not required to develop compatible and interoperable services and it is normal for them to prioritize the development of functionalities or features of the products for business purposes. However, the design approach rarely concerns the human factors and the user experience of practitioners has been largely downplayed. The situation is not only wracked with the technical hardship but also organizational factors, compounded by the regulatory vacuum which allows a “wild” growth of the intertwined eco-systems in the ECRs.

2 Architecture and service-oriented thinking

When we speak, it is not our knowledge of language that generates the sounds—but without them, we could not communicate. Standardization is important if we concern the interconnections between technologies and overarching eco-system. Although standardization could bring negative impacts, e.g., prevent use of alternative technologies, stifle creativity, or lead to abuse of dominant position by over-powerful consortia, its overall impact in modern industry is considered positive (ISUG 2002). But how would this be related to our ECR problems? One way to look at this issue is that standardization is necessary to tear down the technical barriers. With so many stakeholders involved in the eco-system, it hinges on an architecture paradigm that can foster collaboration and bridge the gap between the technology development and diverse business needs. The architectural approach serves as an umbrella and service-oriented architecture (SOA) is a useful reference model, which has not been practiced in the ECR. An EU project is used to illustrate the value of this alternative design approach in this section (EU 2015).

2.1 An architectural approach to the ECR

The nature of disparate functionality showed in the case in section 1.2 reflects the distributed resources for design. If we regard required functionalities as services, then digitalization is a process to add values in generated services (Stickdorn and Schneider 2016). Services in the ECR can be internally formulated, shaped, and presented on a ship system (e.g., machinery data generated in the engine room) or externally created and manipulated on a ship-shore system (e.g., big data calculation and intelligent decision-making support). The technologization can shape a vast space for service providers to innovate with value-added service offering (Stickdorn and Schneider 2016).

The point is not to limit the introduction of new generations of technology into the ECR, but how to govern them from a global perspective. Different pieces of reliable technological components are important but a strategy to govern the technology in order to truly support decision-making is even more important. The ambition of the governance of resources and functions in the ECR would require collective efforts from many stakeholders, not just users but also involved service providers and manufacturers. Recent maritime research on physical ergonomics tried to incorporate human factor principles and knowledge in the engineering process (Mallam et al. 2015, 2017a, b). The idea of integrating participatory practices in design process is very enlightening because both disciplines of participatory design and service design are value-laden, sharing common structures including involvement techniques, cooperative approaches, and emancipatory objectives (Holmlid 2009).

This conceptual paper proposes that the strategy to govern the technology is to have a high-level infrastructural approach that supports scalability, interoperability, and customized integration. Architecture is defined as “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (ISO/IEC/IEEE 2007). The architecture of a system is a metaphor, analogous to the architecture of a building (Perry and Wolf 1992). The architecture is about the structures of the system and behavior, including system elements, properties of the elements, and the relationship among them (Len et al. 2003). It is concerned with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and trade-offs, and esthetics (Booch et al. 1999). Products are services, bringing values to the users. Architectural thinking can provide holistic insights about how we should shape the products or services within human factor concern, i.e., how we should incorporate computerization into the ECR, how we can address the issues of decentralization, maintainability, scalability, information, and function redundancy in a way that does not shrink the space of flexibility and creativity (e.g., leaves out the details of internal implementation) (Len et al. 2003). Dikmans and van Luttikhuizen (2012) deem that “the goal of architecture is to translate the business strategy into appropriate guidelines for standardisation and integration. It is a means to end, making sure that IT can fulfil the business requirements” (p. 20). One of the criteria for choosing a proper architecture is to promote usability and post-deployment extendibility but at the same time, minimize the cost and complexity (Microsoft 2009). Flexibility and adaptability are always appreciated in constructing such a large system. Thus, it requires us to find a way to address the integration and standardization requirements of various stakeholders and offer a sustainable path of incorporating emerging technologies. Architecture itself is not standardization, but serves as an approach to align IT development with business needs by applying appropriate standards. The important concept is to “build capabilities (to prepare optimization and integration), not just fulfil immediate needs” (Dikmans and van Luttikhuizen 2012).

One can roughly use this metaphor to understand our advocated architectural approach: if we do not have an App Store, then it would be difficult to manage endless apps so that the user experience will suffer to some extent. Lundh and Rydstedt (2016) contended that the issues associated with ECRs were simply not a problem of how many more displays should be installed. It is a question of the underlying infrastructure development about how we can harmonize heterogeneous technologies to support supervisory control and rapid information access. The infrastructural development is a key to allow information to be exchanged pertaining to service design. It would likely facilitate the development of a collaborative environment where individual “in-house” development could be shifted to collaborative development. This could imply an important pivot in the shipping domain’s design approach in which a holistic architectural thinking on a global level should be appreciated. However, this is still largely an uncharted territory or much less discussed in terms of maritime informatics (technical point of view) and regulatory support (non-technical point of view).

A closed system such as the ECR seems to have less necessity to be that agile as it might not be as dynamic as a bridge system per se. However, with more real-time IT systems to be set up to build communications and interactions with the bridge (indicated by Fig. 4) and shoreside facilities (e.g., the trend of moving towards autonomous shipping), the whole engine department is likely to become an open system. The problems in the ECR are not just about traditional man-machine system, e.g., design of supervisory control systems (Sheridan 1992, 2002), but also query the relationship between human, technology, and organization (HTO) (Karltun et al. 2017) as well as the work in the future (Karltun et al. 2017; Stanton et al. 2017; Vicente 1999). The central idea is that, in order to surmount barriers that exist in technical level and organizational level, the maritime design thinking has to go beyond the development of a standalone function and recognizes the importance of harmonizing increasing presence of services via systematic integration and standardization. Service-oriented architecture (SOA), an emerging way of thinking in contemporary architectural design (Josuttis 2007), provides great advantages in scaffolding distributed heterogeneous services for higher availability, accessibility, reusability, composability, and discoverability and embraces the cross-platform standards (Dikmans and van Luttikhuizen 2012; Seth et al. 2013; Stickdorn and Schneider 2016). Although itself alone might be insufficient to address all issues regarding HTO, it is a plausible solution to suggest the way forward by breaking the bottleneck of information optimization and allowing the eco-system to scale itself in a more naturalistic manner.

2.2 SOA as a reference model

Confronted with the challenges deeply rooted in the whole eco-system, we propose to use SOA as a reference model to illustrate how an architectural approach could be useful in dealing with unruly technologies. Before more critically examining SOA, it is important to perceive it as an architectural style, which “defines a family of systems in terms of a pattern of structural organization, determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined” (Garlan and Shaw 1994). The focus in the ecological system of an ECR should not be anchored to a desired feature, but the principles to govern endless functions and information in a decision-support manner. What we need is a paradigm to describe the framework of solutions for a set of problems (Crumlish and Malone 2009). This is exactly where SOA’s efficacy lies.

Service-oriented thinking serves as the core, which is not only concerned with operational functions in IT landscape, but also deals with business-aligned enterprise services in the semantics of an enterprise architecture (Rosen et al. 2008). It is ideally fit for an organization that has to frequently handle “regulatory changes, fast-changing demands, markets, and legacy systems” and stay “agile, flexible, and efficient” (Dikmans and van Luttikhuizen 2012), but how exactly would SOA be used to harmonize the ecological complexity in the ECR? There are intertwined internal and external services deployed in the ECR. The service providers could either be manufacturers or companies generating intelligent services aiming at improved system performance, and the service consumers could be IT technicians who integrate services and develop customized solutions or the end users like ship engineers. From a function’s level, a service can have three different components: interface (how a consumer uses or access a service), contract (service content, quality, policies, context in which the services will be provided), and detailed implementation (Dikmans and van Luttikhuizen 2012). The idea of SOA is to enumerate “functions” as services, organize them into logic domains, and try to be agile and efficient in resource-reuse (Daigneau 2012). In order to minimize the effect of modification, it is important to design services as tiny manageable pieces with a clear set of capabilities (Dikmans and van Luttikhuizen 2012; Josuttis 2007). This is a process-oriented characteristic in SOA implementation (Havey 2008).

Operationally, SOA means to expose the interfaces and contracts in an open service registry (similar to a “yellow book”) hosted on a digital platform to the service consumers (in most cases the IT technicians) for reuse and integration, but not the implementation details of the concrete service data (Seth et al. 2013). Web services are the key enablers of the SOA which are essentially a set of open standards and protocols, such as REST (representational state transfer), SOAP, WSDL, and XML (Daigneau 2012; Dikmans and van Luttikhuizen 2012; Rosen et al. 2008). To overcome the technical barriers, it is important to expose the service interfaces and contracts in a service registry to enable cross-platform communication between distributed systems with different owners, vendors, and manufacturers (Josuttis 2007). The open standards embodied by the web services provide the common vocabulary for services to be interoperable, integrable, and adaptable, but on the other hand, protect the business value of the service providers by hiding the underlying technical complexity and details (Dikmans and van Luttikhuizen 2012). Essentially, standardization is an inherent notion in the SOA reference model. It enables interoperability and information exchange while not limiting flexibility, empowering participatory cross-organizational design and development aiming for improved user experience and system resilience. By leverage, the power of web services, the back-end of the eco-system could be moving towards a collaborative platform—to allow multiple stakeholders to not only dissolve the technical barriers by developing services that are characterized with interoperability, agility, and flexibility, but also to develop a business synergy, to form the industrial symbiosis, to really focus on the value-added service development for end users.

There can be numerous business cases to be developed to better exploit the advantage of information technologies under SOA. One relevant instance is the Maritime Connectivity Platform (MCP, formerly known as Maritime Cloud) developed in the EU project “EfficienSea 2” (EU 2015) in the e-navigation framework—an ongoing development concept addressing the need to use electronic means to harmonize “collection, integration, exchange, presentation and analysis of marine information on board and ashore, enhance navigation, and related services for safety and security at sea” (IMO 2014a). The development of e-navigation solutions, to a large degree, depends on the infrastructure of the MCP or Maritime Cloud (DMA 2016b), whose intention is to utilize SOA to connect all maritime stakeholders for information exchange (DMA 2016a).

Figure 5 presents how the MCP is utilizing the concept of SOA. Today, many services are provided by different manufacturers or service providers for different stakeholders, such as navigation, reporting, weather information, and port information. A start-up company X specializing in big data computation can integrate the intrinsic information services provided by radar manufacturers Y and shore-based meteorological information provided by service provider Z to provide an intelligent decision support on energy-efficient route planning for less fuel consumption. New manufacturers could also sail in the market with their featured integrated services; the development in the back-end is going to be value and business oriented rather than a vendor-dependent process, e.g., the consumers do not have to account for the changes that the service owner wants to make.

Fig. 5
figure 5

Maritime Connectivity Platform (Maritime Cloud) using SOA to connect different stakeholders and integrate distribute resources (DMA 2016a)

Full size image

Although the MCP is ad hoc for ship bridges, the engine and bridge departments share the same problem that growing technologies need to be managed on a higher level in the infrastructure. A difference between these two departments is that the navigational equipment used in the bridge department is highly regulated and newly added IT systems may only be used as the optional back bridge solutions, while the ECR does not really have that mandatory regulations how we introduce new IT solutions. The navigators would probably be more efficient to develop their situation awareness when looking the outside through the windows, compared to the engineers who must rely on digital information on distributed displays to diagnose what causes an alarm. This difference might create more needs for the ECR to consider using MCP to integrate information, manage technologies, and shape the eco-system. In the background section, we have presented the reality by re-examining a case in the ECR—the developed and deployed distributed systems have made presentations of various alarm indications ambiguous and confusing for the engineers. The key to obtain a cross-platform overview with high consistency, accessibility, readability, and discoverability lies in the interoperability that requires both service-oriented developments from service providers’ side and easy access to standardization application from the service consumers’ side. With SOA implemented on the platform of the MCP, the hierarchical structure of standards will provide ship owner possibilities to integrate and optimize information without bothering about the implementation details from service providers. With the introduction of the MCP, service providers and manufacturers can also separate core functionalities development from interface design and standardization establishment, fundamentally improving interoperability of the systems in the ECR.

The MCP directly concerns the development work in the back-end, i.e., how we manage unruly technologies with design, deployment, and governance of standardization. However, such efforts done in the back-end have always aimed to create gains in the front-end—an improved user experience for the goals of safety and efficiency. For example, from the design and implementation perspective, the establishment of the MCP would allow a desired overview to be better aligned with the physical and cognitive ergonomics principles. Table 1 summarizes the benefit synthesis for both back-end and front-end users in the context of the MCP.

Table 1 SOA’s benefit synthesis for back-end and front-end users in the context of the MCP
Full size table

Beside the benefits that are grounded in the technical aspects, SOA could be used for organizing and utilizing capabilities that may be under the control of different ownership domains (OASIS 2006), as shown in the stakeholder map of Fig. 5. It could enable different companies to independently implement services that meet their immediate needs, yet it can be also combined into higher level business processes and enterprise solutions (Rosen et al. 2008). This might be applicable for various regulatory bodies and high-level policy makers. In a latest workshop of the MCP, the participated maritime stakeholders of interest concluded that “the MCP is expected to take down barriers of language and communication, it will be a platform for new business opportunities. The strengths are the introduction of standards, inter-operability and the support of international associations” (Doyle and Ward 2017). The goal is to create an infrastructure in the maritime domain to enable information exchange and optimization, which in the end would influence safety, productiveness, and efficiency of system performance and even the whole ecology.

Confronted with the problems identified in the work situation on board, little suggestions on solutions have been proposed up to now. In the shipping domain, what we commonly see is the advocation of human-centered design approach for individual system design and development (Abeysiriwardhane et al. 2016; Costa et al. 2017) or the strategy of development around the bridge (IMO 2014b), but they do not necessarily address the complexity in the ECR eco-system. This architectural thinking behind the MCP provides an alternative path to approach system engineering: How legacy systems could remain in use while the introduction of new systems could be compatible with existing functions? How novel IT solutions should be developed and deployed with more human factor concerns? How heterogeneous and distributed information can be interoperable and presented to support the operators to quickly understand situations and make decisions? SOA creates a vast space of opportunities to tackle with these questions in the ECR. The prioritization of “architecture” of the system reveals a different mind-set to deal with increasing IT requirements compared to a common solution of mechanically setting up new screens and monitors. It is believed that this will create value not only for the sharp front-end users who interact and operate in the field but also the blunt back-end maritime authorities and policy makers who design strategies and set up regulations. The impact of standardization to shape the eco-system for sustainable technology innovations catered for the user’s needs should not be underestimated.

3 Theoretical reflections: drifting into failures

One important design goal for any complex high-risk human-technology system should be enhancing the system’s capability to maintain in the safety boundary in the “incubation period”—a period in which the incremental changes that may later contribute to a system-wide collapse got unnoticed (Dekker and Pruchnicki 2014; Turner 1978). Proactive adaptation of the interface to support monitoring (Mumaw et al. 2000) or the “information overview” feature we mentioned earlier (Lundh et al. 2011; Wagner et al. 2008) could be two useful cognitive instrument to support operators to respond flexibly in an increased margin of maneuverability, but we argue that a more important thing for design is to take a systems perspective to understand the eco-system’s complexity. Flach (2011) has characterized this “complexity” as dimensionality of the problem space (i.e., the size of the variables) and interactions between dimensions. With the un-eliminated legacy systems and rapid development of model IT systems, data, the oil of the digital era, is generated ubiquitously. The growing internal interactions and evolving external interactions that aim to extract the value out of data reveal the high volume of varieties of the world. The critical thing for the blunt-end is to consider how to shape the system’s capability in dealing with complexity—ability to have adaptable reserves and flexibility to accommodate the unforeseen contingencies (Mikkers 2010; Nemeth 2008). This is beyond the idea of using design to address individual limitations, but is about making the whole system more resilient. Resilience is about having adaptability and flexibility in the system (Hollnagel 2013). This would require various stakeholders (e.g., IT practitioners, service providers, manufacturers, regulatory bodies, and other organizations) in the shipping industry to posit the digitalization and innovation development view on holistic and sustainable terms.

One prominent need is to have that adaptability and flexibility coming from the aforementioned booming unruly technologies, both in size and complexity, spreading around the whole workplace, contributing to in-transparency in the controlled process, and gradually shifting the system from a closed one to an open one. By having more “cards” or technological solutions on the table, we may have more flexibilities inherent in the technical artifacts themselves, but they may create new layers of complexities (Woods 1993) and continually require operators to adapt in high-risk work (Rankin et al. 2014). Woods (1993) explained that this is because “the technological flexibilities that simply create burdens on the practitioners” could prevail over “the technological flexibilities that are used to increase the range of practitioner adaptive response to the variability resident in the field of activity” (p. 19). We should not ignore the essential role of performance variability in pursuit of system’s resilience—human should no longer be seen as hazards to the system (Dekker 2004; Hollnagel 2009). Within a system that constantly experience changes, an organization could be deemed as a set of changing adaptive processes or sub-systems (Dekker and Pruchnicki 2014; Leveson 2011). It is critical that the fundamental settings of the system (i.e., architecture) can increase the safety margin and support the diverse use and functions (so that the operators with imperfect knowledge to stay responsive to various constraints in the context). The architectural understanding of the whole system aims to recognize the adaptability and support the performance variability with a holistic thinking rather than blindly introducing immediate solutions to fix “patches.” The focus of complex system design should not be on the scrutiny of individual components in a manner attempting to meeting new requirements by adding more “cards” (e.g., features, functionalities with new layers/generations of technology). Dekker (2011) contended that a deeper understanding of the system must go beyond hunting the component that went wrong. Instead, the focus should be the “webs of relationships,” the global structure and environment because they will likely shape the organization’s capability to accommodate and allow human adaptation effectively to the complexities (Dekker and Pruchnicki 2014; Woods 2003).

It is worth pointing out that adaptations cannot only be viewed from the sharp-end practitioners (Rankin et al. 2014) but also the blunt-end designers, regulators, policy makers, and even the whole regulatory bodies, who set the goal-based standards for achieving safety and efficiency but provide limited regulatory support in what and how (Mallam and Lundh 2013). Researchers have kept mentioning the problems in ECRs but still there are few concrete solutions being proposed. We believe the considerations on the fundamental structure or the architecture of the system, even from a technical point of view as a starting point, is essential to provide a way forward to address the issue onboard that is characterized of these emerging unruly technologies. It is important to shift our focus only from patching individual problems locally to a holistic architectural thinking regarding the maritime eco-system development. Shipping is a highly technology-driven but also conservative domain with many stakeholders. When confronted with a problem, most rational decisions were made locally by the actors involved. Rationality is certainly not a bad thing. Setting up new screens or new systems are decisions based on rational thinking and demands. From the perspective of complexity, the problem is that local adaptiveness can lead to “illusion of assistance” or “mis-calibration” of the dynamic situation, as it might lead the regulators and policy makers to ignore the mal-adaptiveness on a global scale (Dekker and Pruchnicki 2014). This is worrisome when considering the technology is growing so rapidly across industries in modern society. Computing power has doubled more than 27 times since the birth of the integrated circuit in 1958 and the globalization has been making the world more connected than ever (Ford 2015). The unlimited possibilities and general success today we see in the IT development across all transportation sectors do not mean such a direct way of introducing digitalization and value-added services are immune to risks. If the technological components or the retrofitting work on legacy systems are not monitored and regulated with a holistic thinking (e.g., overall system structures, inter-connected relationships, and standardization requirements for interoperability), the technologies would not be harmonized in the infrastructure, then the risks could be accumulated, proliferated, and promulgated without notice (i.e., slowly drift into failure) until at some point we find that our workplace is full of system “chaos.” These “chaos” may result in more and more work demands on workers described earlier, likely leading to more human errors.

The architectural thinking in this conceptual paper is not about meddling how technologies are implemented in detail for meeting new requirements. It is concerned about the need of introducing necessary standardization to allow a more efficient and sustainable system to be developed. Standardization, as an inherent notion in the architectural approach, which plausibly limits the possibilities of being versatile and flexible, is essentially building this new kind of “organisational monitoring and learning” (p. 541) that the system needs to stay in the safety boundary (Dekker and Pruchnicki 2014). For instance, SOA has the potential to build the vocabulary to harness the complexity in the intricate eco-system by incorporating standardization and paradigm thinking in adaptive, global, and dynamic terms. The MCP, as one example implementing SOA, takes advantage of standardization and aims to shape a collaborative space to allow various stakeholders to concentrate on their own business-aligned value-added service development and quality enhancement cost efficiently. Will standardization hinder technological advancement and innovations? Not necessarily. For example, the standardization in the MCP solution is implemented in a hierarchical way, from service specification (higher level), to design and instance (lower-level) (DMA 2016b). It means the degree of standardization could vary depending on the business needs. The higher level standards identification and coordination needs to be carried out among standards organizations, such as IMO, ITU Radiocommunication Sector (ITU-R), International Hydrographic Organization (IHO), ISO, IEC, International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA), European Conference of Postal and Telecommunications Administrations (CEPT), and European Telecommunications Standards Institute (ETSI) and their relevant committees as well as working groups (IALA 2016). Without the support from these regulatory bodies and standards organizations, the benefits of an architectural approach to manage technologies in the ECR could be limited. The point this paper wants to make is that we need to have a fundamental infrastructure in the shipping domain to enhance sustainable technology development. The App Store works successfully not because of one or two killer apps, but because of its robust eco-system that allows more innovative apps to be developed, published, searched, and used—something that our maritime industry may need to reflect upon in the digital age. As more IT solutions being introduced onboard or onshore (e.g., big data applications, cloud computing services, block-chain applications, virtual reality, and augmented reality applications), the necessity of governing technologies has never been more important. Without the concerns on the infrastructure and standardization, the regulatory support would be difficult to keep up the pace with technological progress that the shipping industry is making. Like the paradox mentioned by Dekker and Pruchnicki (2014) that “organizations fail because they are successful,” we also have something to grapple with for a complex sociotechnical system like an ECR: “flexibilities succeed because they are standardized.” This chimes with our rhetoric put earlier—the concern is never to limit the development of technological advancement but manage the eco-system in the long perspective.

4 Conclusions

Engine control rooms (ECRs) have been characterized of growing presence of IT applications, which makes the work environment increasingly complex. This paper has proposed to shift the focus from patching individual problems by continuously introducing more and more so-called intelligent artifacts to a holistic thinking with a service-oriented architectural view. Certain degree of standardization is considered as a prerequisite to allow technologies to be better integrated and governed in the back-end, which is tightly associated with the user experience and safety performance in the front end. The trickle-down regulations in the maritime domain must consider the configurations between the human workers and the emerging technologies to address the increasing complexity onboard. Without holistic systems thinking on a global scale, whatever tech-innovations we introduce to the workplace today will likely become unruly technologies, which would eventually erode the adaptive capacity of the man-machine system (Patterson et al. 2007) and compromise safety and efficiency.