Skip to main content

Managing unruly technologies in the engine control room: from problem patching to an architectural thinking and standardization


In recent years, the work in engine control rooms (ECRs) onboard ships is becoming increasingly demanding and complex due to growing presence of modern information technology (IT) applications introduced in a problem-patching fashion. Previous studies about ECRs discussed the design issues associated with physical and cognitive ergonomics and lack of regulatory support. This paper has re-examined a design case in an ECR on a merchant ship and discussed the potential of a service-oriented architectural approach to manage emerging unruly technologies and integrate distributed resources in the maritime human-technology system. An EU project was introduced to illustrate the value of this design approach. Confronted with the complexity issues residing in a sociotechnical system like the ECR, this conceptual paper suggests a shift of focus from patching individual problems locally to a holistic systems perspective on the maritime eco-system development, which would likely require more collaborative efforts of various maritime stakeholders in practice. Certain extent of mandatory standardization for deploying and managing information systems is considered to be critical in these collaborative endeavors.


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.

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

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)

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)

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.

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

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.

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).


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.

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).

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.

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)

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

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.

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.


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.


  1. Aas AL, Skramstad T (2010) A case study of ISO 11064 in control centre design in the Norwegian petroleum industry. Appl Ergon 42:62–70.

    Article  Google Scholar 

  2. Abeysiriwardhane A, Lützhöft M, Petersen ES, Enshaei H (2016) Human-centred design knowledge into maritime engineering education; theoretical framework. Australas J Eng Educ 21:49–60.

    Article  Google Scholar 

  3. Abras C, Maloney-Krichmar D, Preece J (2004) User-centered design Bainbridge, W Encyclopedia of Human-Computer Interaction, vol 37. Sage Publications, Thousand Oaks, pp 445–456

    Google Scholar 

  4. Allen P (2009) Perceptions of technology at sea amongst British seafaring officers. Ergonomics 52:1206–1214.

    Article  Google Scholar 

  5. Andersson M, Lützhöft M (2007) Engine control rooms - human factors. In: RINA, Royal Institution of Naval Architects International Conference - human factors in ship design, safety and operation - papers. pp 65–68

  6. Bainbridge L (1983) Ironies of automation. Automatica 19:775–779.

    Article  Google Scholar 

  7. Booch G, Rumbaugh J, Jacobson I (1999) Unified modeling language - user’s guide. Addison-Wesley, Boston

    Google Scholar 

  8. Bower JL, Christensen CM (1995) Disruptive technologies: catching the wave

  9. Chavaillaz A, Wastell D, Sauer J (2016) System reliability, performance and trust in adaptable automation. Appl Ergon 52:333–342.

    Article  Google Scholar 

  10. CIRM/BIMCO (2017) Industry standard on software maintenance of shipboard equipment. CIRM and BIMCO

  11. Costa NA, Holder E, MacKinnon SN (2017) Implementing human centred design in the context of a graphical user interface redesign for ship manoeuvring. International Journal of Human-Computer Studies 100:55–65.

    Article  Google Scholar 

  12. Crumlish C, Malone E (2009) Designing social interfaces. O’Reilly Media, Inc, Sebastopol

    Google Scholar 

  13. Daigneau R (2012) Service design patterns: fundamental design solutions for SOAP/WSDL and RESTful web services. Addison-Wesley, Boston

    Google Scholar 

  14. Dekker S (2004) Ten questions about human error. Lawrence Erlbaum, Mahwah

    Google Scholar 

  15. Dekker S (2011) Drift into failure: from hunting broken components to understanding complex systems. AshgatePublishing Co, Farnham

    Google Scholar 

  16. Dekker S, Pruchnicki S (2014) Drifting into failure: theorising the dynamics of disaster incubation. Theor Issues Ergon Sci 15:534–544.

    Article  Google Scholar 

  17. Dikmans L, van Luttikhuizen R (2012) SOA made simple. Packt Publishing, Birmingham

    Google Scholar 

  18. DMA (2016a) Maritime Cloud conceptual model. Danish Maritime Authority. Accessed Sep 14 2018

  19. DMA (2016b) Mid-Term Periodic Technical Report, Part B. EfficienSea2 - efficient, safe and sustainable traffic at sea. Danish Maritime Authority

  20. Doyle S, Ward N (2017) Deliverable D1.28 - how to run the mcp (maritime connectivity platform). IALA, Paris

    Google Scholar 

  21. Endsley MR (2011) Designing for situation awareness: an approach to user-centered design, 2nd edn. CRC Press, Inc, Boca Raton

    Book  Google Scholar 

  22. EU (2015) EfficienSea 2 - efficient, safe and sustainable traffic at sea. European Commission. Accessed Sep 13 2018

  23. Flach JM (2011) Complexity: learning to muddle through. Cogn Tech Work 14:187–197.

    Article  Google Scholar 

  24. Foord AG, Gulland WG (2006) Can technology eliminate human error? Process Saf Environ Prot 84:171–173.

    Article  Google Scholar 

  25. Ford M (2015) Rise of the robots: technology and the threat of a jobless future. Basic Books, New York, USA

    Google Scholar 

  26. Garlan D, Shaw M (1994) An introduction to software architecture. Carnegie Mellon University, Pittsburgh

    Google Scholar 

  27. Gentzsch W, Purwanto A, Reyer M (2016) Cloud computing for CFD based on novel software containers. In: 15th International Conference on Computer and IT Applications in the Maritime Industries - COMPIT ‘16, Lecce, Italy

  28. Grundevik P, Lundh M, Wagner E (2009) Engine control room - human factors. In: RINA, Royal Institution of Naval Architects International Conference - human factors in ship design, safety and operation - papers, pp 61–67

  29. Gubbi J, Buyya R, Marusic S, Palaniswami M (2013) Internet of things (IoT): a vision, architectural elements, and future directions. Futur Gener Comput Syst 29:1645–1660.

    Article  Google Scholar 

  30. Hancock PA (2013) Automation: how much is too much? Ergonomics 57:449–454.

    Article  Google Scholar 

  31. Havey M (2008) SOA cookbook - design recipes for building better SOA processes. Packt Publishing, Birmingham

    Google Scholar 

  32. Håvold JI (2015) Stress on the bridge of offshore vessels: examples from the North Sea. Saf Sci 71(Part B):160–166.

    Article  Google Scholar 

  33. Heilig L, Voß S (2016) A holistic framework for security and privacy management in cloud-based smart ports. In: 15th International Conference on Computer and IT Applications in the Maritime Industries - COMPIT ‘16, Lecce Italy

  34. Hetherington C, Flin R, Mearns K (2006) Safety in shipping: the human element. J Saf Res 37:401–411.

    Article  Google Scholar 

  35. Hollnagel E (2009) The ETTO principle: efficiency-thoroughness trade-off: why things that go right sometimes go wrong. Ashgate Publishing Limited, Farnham

    Google Scholar 

  36. Hollnagel E (2012) Resilience engineering and the systemic view of safety at work: why work-as-done is not the same as work-as-imagined. Paper presented at the Bericht zum 58. Kongress der Gesellschaft für Arbeitswissenschaft vom 22 bis 24 Februar 2012. Dortmund

  37. Hollnagel E (2013) Resilience engineering in practice: a guidebook. Ashgate Publishing, Ltd., Farnham

    Google Scholar 

  38. Holmlid S (2009) Participative, co-operative, emancipatory: from participatory design to service design. Paper presented at the First Nordic Conference on Service Design and Service Innovation, Oslo, 24th - 26th November

  39. House C, Place C (2006) Report on the investigation of the engine failure of Savannah Express and her subsequent contact with a linkspan at Southampton Docks. Marine Accident Investigation Branch, Southampton, United Kingdom

  40. IALA (2016) D1.5 Report on ongoing standardization work relevant to the project. International Association of Marine Aids to Navigation and Lighthouse Authorities

  41. IEC (1989) IEC-964: Design for control rooms of nuclear power plants. The International Electrotechnical Commission, Geneva

    Google Scholar 

  42. IMO (1998) Guidelines for engine-room layout, design and arrangement (MSC/Circ.834). International Maritime Organization, London

    Google Scholar 

  43. IMO (2009) International convention for the safety of life at sea, 5th edn. International Maritime Organization, London

    Google Scholar 

  44. IMO (2014a) E-navigation. Accessed Mar 6 2017

  45. IMO (2014b) Strategy for the development and implementation of e-navigation. Accessed Mar 6 2017

  46. ISO (2008) ISO 11064 - 5: ergonomic design of control centres. The international organization for standardization, Geneva

    Google Scholar 

  47. ISO (2010) ISO 9241-210: ergonomics of human-system interaction - part 210: human-centred design for interactive systems. The international organization for standardization, Geneva

    Google Scholar 

  48. ISO/IEC/IEEE (2007) ISO/IEC/IEEE 42010: a conceptual model of architecture description vol 42010:2007

  49. ISUG (2002) Study into the impact of standardization, final report to DG Enterprise. Impacts of standards users group, Ireland

  50. Ivergård T, Hunt B (2009) Handbook of control room design and ergonomics: a perspective for the future. CRC Press, Boca Raton

    Google Scholar 

  51. Josuttis NM (2007) SOA in practice. O’Reilly Media, Inc, Sebastopol

    Google Scholar 

  52. Kahneman D (1973) Attention and effort, vol 1063. Prentice-Hall, Englewood Cliffs

    Google Scholar 

  53. Karltun A, Karltun J, Berglund M, Eklund J (2017) HTO – a complementary ergonomics approach. Appl Ergon 59(Part A):182–190.

    Article  Google Scholar 

  54. Kjellén U (2007) Safety in the design of offshore platforms: integrated safety versus safety as an add-on characteristic. Saf Sci 45:107–127.

    Article  Google Scholar 

  55. Koga S (2015) Major challenges and solutions for utilizing big data in the maritime industry. Dissertation, World Maritime University

  56. Landauer T (1995) The trouble with computers usefulness usability and productivity. MIT press, Cambridge

    Google Scholar 

  57. Len B, Clements P, Kazman R (2003) Software architecture in practice, 2nd edn. Addison-Wesley Professional, Boston

    Google Scholar 

  58. Leveson NG (2011) Applying systems thinking to analyze and learn from events. Saf Sci 49:55–64.

    Article  Google Scholar 

  59. Lukas UF (2010) Virtual and augmented reality for the maritime sector – applications and requirements. IFAC Proc Vol 43:196–200.

    Article  Google Scholar 

  60. Lundh M (2010) A life on the ocean wave - exploring the interaction between the crew and their adaption to the development of the work situation on board Swedish merchant ships. Dissertation, Chalmers University of Technology

  61. Lundh M (2014) A static approach to work practices in a dynamic socio-technical reality - the changes in work demand of marine engineers marine technical notes, IMAREST Publication No. 3/14

  62. Lundh M, Rydstedt LW (2016) A static organization in a dynamic context – a qualitative study of changes in working conditions for Swedish engine officers. Appl Ergon 55:1–7.

    Article  Google Scholar 

  63. Lundh M, Lützhöft M, Rydstedt L, Dahlman J (2011) Working conditions in the engine department – a qualitative study among engine room personnel on board Swedish merchant ships. Appl Ergon 42:384–390.

    Article  Google Scholar 

  64. Lundh M, MacKinnon S, Man Y (2015) Transparency within automated engine control systems: the case of the Savannah Express. Paper presented at the NAV 2015 18th International Conference on Ships and Shipping Research, Milan, Italy, June 24 - 26

  65. Lützhöft M (2004) “The technology is great when it works”: maritime technology and human integration on the ship’s bridge. Linköping University, The Institute of Technology

  66. Lützhöft M, Lundh M (2009) Marine application of control systems. In: Ivergård T, Hunt B (eds) Handbook of control room design and ergonomics - a perspective for the future. CRS Press, Boca Raton, pp 227–261

    Google Scholar 

  67. Maguire M (2001) Methods to support human-centred design. Int J Hum Comput Stud 55:587–634.

    Article  Google Scholar 

  68. Mallam SC (2014) The human element in marine engine department operation: human factors & ergonomics knowledge mobilization in ship design & construction. Chalmers University of Technology

  69. Mallam SC, Lundh M (2013) Ship engine control room design: analysis of current human factors & ergonomics regulations & future directions. Proceedings of the Human Factors and Ergonomics Society Annual Meeting 57:521–525

    Article  Google Scholar 

  70. Mallam SC, Lundh M (2014) Conceptual ship design, general arrangement & integration of the human element: a proposed framework for the engine department work environment. In: Proceedings: 11th International Symposium on Human Factors in Organisational Design and Management & 46th Nordic Ergonomics Society Conference. pp 829–834

  71. Mallam SC, Lundh M (2016) The physical work environment and end-user requirements: investigating marine engineering officers’ operational demands and ship design. Work 54:989–1000.

    Article  Google Scholar 

  72. Mallam SC, Lundh M, MacKinnon SN (2015) Integrating human factors & ergonomics in large-scale engineering projects: investigating a practical approach for ship design. Int J Ind Ergon 50:62–72.

    Article  Google Scholar 

  73. Mallam SC, Lundh M, MacKinnon SN (2017a) Evaluating a digital ship design tool prototype: designers’ perceptions of novel ergonomics software. Appl Ergon 59(Part A):19–26.

    Article  Google Scholar 

  74. Mallam SC, Lundh M, MacKinnon SN (2017b) Integrating participatory practices in ship design and construction. Ergon Des 1064804616684406.

    Article  Google Scholar 

  75. Man Y, Lützhöft M, Costa N, Lundh M, MacKinnon SN (2017) Gaps between users and designers: a usability study about a tablet-based application used on the ship bridges vol advances in intelligent systems and computing. Springer international publishing AG.

    Google Scholar 

  76. Man Y, Lundh M, MacKinnon SN (2018) Maritime energy efficiency in a sociotechnical system: a collaborative learning synergy via mediating technologies. TransNav 12:239–250.

    Article  Google Scholar 

  77. Man Y, Lundh M, MacKinnon SN (2019) Facing the new technology landscape in the maritime domain: knowledge mobilisation, networks and management in human-machine collaboration. In: 9th International Conference on Applied Human Factors and Ergonomics, Orlando, Florida, USA. Advances in Human Aspects of Transportation. Springer International Publishing, pp 231–242

  78. Mao J-Y, Vredenburg K, Smith PW, Carey T (2001) User-centered design methods in practice: a survey of the state of the art. Paper presented at the Proceedings of the 2001 conference of the Centre for Advanced Studies on Collaborative research, Toronto, Ontario, Canada

  79. Mårtensson M (2006) Sjöfarten som ett socialt system - om handelssjöfart, risk och säkerhet (The shipping industry as a social system - about the merchant navy, risk and safety). Luleå tekniska universitet

  80. Microsoft (2009) What is software architecture? Accessed May 9 2017

  81. Mikkers M (2010) Resilience engineering perspectives, Christopher P. Nemeth, Erik Hollnagel, Sidney Dekker. Preparation and restoration, vol 2. Ashgate Publishing Limited, Farnhem, Surrey, England (2009) Safety Sci 48:829–830.

  82. Mosier KL, Skitka LJ, Dunbar M, McDonnell L (2001) Aircrews and automation bias: the advantages of teamwork? Int J Aviat Psychol 11:1–14.

    Article  Google Scholar 

  83. Mumaw RJ, Roth EM, Vicente KJ, Burns CM (2000) There is more to monitoring a nuclear power plant than meets the eye. Hum Factors 42:36–55.

    Article  Google Scholar 

  84. Navon D (1985) Attention division or attention sharing attention and performance XI. 133:146

  85. Nemeth CP (2008) Resilience engineering perspectives vol 1. Remaining sensitive to the possibility of failure. Ashgate Publishing Ltd, Aldershot

    Google Scholar 

  86. Norman DA (1990) The problem of automation: inappropriate feedback and interaction, not over-automation. In: Broadbent DE, Baddeley A, Reason JT (eds) Human factors in hazardous situations. Oxford University Press, Oxford, pp 585–593

    Google Scholar 

  87. OASIS (2006) Reference model for service oriented architecture 1.0. Accessed 24 Apr 2017

  88. Orosa JA, Oliveira AC (2010) Assessment of work-related risk criteria onboard a ship as an aid to designing its onboard environment. J Mar Sci Technol 15:16–22.

    Article  Google Scholar 

  89. Parker AW, Hubinger LM, Green S, Sargent L, Boyd R (2002) Health stress and fatigue in shipping. Australian Maritime Safety Agency

  90. Patterson ES, Woods DD, Cook RI, Render ML (2007) Collaborative cross-checking to enhance resilience. Cogn Tech Work 9:155–162.

    Article  Google Scholar 

  91. Perry DE, Wolf AL (1992) Foundations for the study of software architecture. ACM SIGSOFT Softw Eng Notes 17:40–52.

    Article  Google Scholar 

  92. PSA (2002) Guidelines to regulations relating to design and outfitting of facilities etc. in the petroleum activities (the facilities regulations). Petroleum Safety Authority Norway (PSA), Norwegian Pollution Control Authority (SFT), Norwegian Social and Health Directorate (NSHD)

  93. Rankin A, Lundberg J, Woltjer R, Rollenhagen C, Hollnagel E (2014) Resilience in everyday operations: a framework for analyzing adaptations in high-risk work. J Cogn Eng Decis Mak 8:78–97.

    Article  Google Scholar 

  94. Rasmussen J, Pejtersen AM, Goodstein LP (1994) Cognitive systems engineering. Wiley, Hoboken

    Google Scholar 

  95. Reason J (2000) Human error: models and management BMJ. Br Med J 320:768–770

    Article  Google Scholar 

  96. Rosen M, Lublinsky B, Smith KT, Balcer MJ (2008) Applied SOA: service-oriented architecture and design strategies. Wiley Publishing, Inc, Indianapolis

    Google Scholar 

  97. Sauer J, Chavaillaz A, Wastell D (2015) Experience of automation failures in training: effects on trust, automation bias, complacency, and performance. Ergonomics 59:1–28.

    Article  Google Scholar 

  98. Seth A, Aggarwal H, Singla AR (2013) Framework for business values chain activities using SOA and cloud. Int J Inf Technol Commun Converg 2:281–294.

    Article  Google Scholar 

  99. Sheridan TB (1992) Telerobotics, automation and human supervisory control. MIT Press, Cambridge

    Google Scholar 

  100. Sheridan TB (2002) Humans and automation: system design and research issues. Wiley, New York

    Google Scholar 

  101. Sheridan TB (2016) Human–robot interaction: status and challenges. Hum Factors 58:525–532.

    Article  Google Scholar 

  102. Skitka L, Mosier KL, Burdick M (1999) Does automation bias decision-making? Int J Hum Comput Stud 51:991–1006.

    Article  Google Scholar 

  103. Skitka L, Mosier KL, Burdick M (2000) Accountability and automation bias. Int J Hum Comput Stud 52:701–717.

    Article  Google Scholar 

  104. Stanton NA, Salmon P, Jenkins D, Walker G (2010) Human factors in the design and evaluation of central control room operations. CRC Press, Boca Raton

    Google Scholar 

  105. Stanton NA, Salmon PM, Walker GH, Jenkins DP (2017) Cognitive work analysis: applications, extensions and future directions. Taylor & Francis Group

  106. Stickdorn M, Schneider J (2016) This is service design thinking: basics, tools, cases. BIS Publishers, The Netherlands

    Google Scholar 

  107. Stopford M (2009) Maritime economics, 3rd edn. Routledge, Milton Park, Abingdon, Oxon United Kingdom

    Book  Google Scholar 

  108. Trakada G, Chrousos G, Pejovic S, Vgontzas A (2007) Sleep apnea and its association with the stress system, inflammation, insulin resistance and visceral obesity. Sleep Med Clin 2:251–261.

    Article  Google Scholar 

  109. Turner BA (1978) Man-made disasters. Wykeham Publications, London

    Google Scholar 

  110. van Dokkum K (2013) Ship knowledge, 8th edn. Dokmar Maritime Publishers BV, Enkhuizen

    Google Scholar 

  111. Vicente KJ (1999) Cognitive work analysis: toward safe, productive, and healthy computer-based work. Lawrence Erlbaum Associates Inc., Mahwah

    Google Scholar 

  112. Viktorelius M (2017) The human and social dimension of energy efficient ship operation. Paper presented at the The International Conference on Maritime Energy Management, Malmö, Sweden, 24–25 2017

  113. Wagner E, Lundh M, Grundevik P (2008) Engine control rooms – human factors field studies. MSI Design, Chalmers University of Technology, SSPA, Gothenburg, Sweden

  114. Woods DD (1993) The price of flexibility. Paper presented at the Proceedings of the 1st international conference on Intelligent user interfaces, Orlando, Florida, USA,

  115. Woods DD (2003) Creating foresight: how resilience engineering can transform NASA’s approach to risky decision making. Paper presented at the US Senate Testimony on The Future of NASA for Committee on Commerce, Science and Transportation, John McCain, Chair, Washington, DC,

Download references


This work was financially supported by the Kungl. Vetenskaps- och Vitterhets-Samhället i Göteborg (KVVS).

Author information



Corresponding author

Correspondence to Yemao Man.

Rights and permissions

Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (, which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Man, Y., Lundh, M. & MacKinnon, S.N. Managing unruly technologies in the engine control room: from problem patching to an architectural thinking and standardization. WMU J Marit Affairs 17, 497–519 (2018).

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI:


  • Engine control room
  • Information technology
  • Maritime industry
  • Service-oriented architecture
  • Standardization
  • Systems thinking