1 Introduction

Human cyber-physical systems (HCPSs) can be considered state-of-the-art information and communications technology (ICT) that incorporate human factors in the development and integration of systems comprising of cyber and physical layers (Romero et al. 2016; Putnik et al. 2019; Liu and Wang 2020). Cyber layers can consist of software computations and decision making, and physical layers are physical infrastructures and processes, where humans are (physically) present (Putnik et al. 2019; Liu and Wang 2020).

Means of developing HCPSs through defining the elements within the physical and cyber layers, and the connections and interactions between them, appear to vary in literature (Liu and Wang 2020). Advances in cyber-physical system (CPS) research reveal that the role of a human in a CPS can be categorized into (Yilma et al. 2021):

  • Human as a sensor – humans are seen as sources of information for CPSs, providing information, which are considered observations, to the CPSs through devices.

  • Human as a system component – humans are integral parts of the CPSs, participating as active resources in the CPSs by contributing to and using the CPSs.

A universally accepted position of the human in an HCPS does not appear to transpire (Liu and Wang 2020; Yilma et al. 2021). Questions that remain are:

  • If humans are solely considered a physical entity, do they have the same status as the CPSs they interact with?

  • If human factors are integrated into CPSs through behavioral or social models, do humans have models uniquely associated with them that they can interact with or are humans disconnected from models in the cyber layer and remain users of CPSs that house generic human models?

The contribution of this paper is two-fold. The first contribution aims to address questions like the above-mentioned by presenting an architecture for HCPSs that defines the entities within the physical and cyber layers, and the connections and interactions between the entities. In the architecture, a human is present in the physical layer and is elevated to CPS status through an associated, personalized digital representation that they can interact with. The second contribution is the application of an HCPS as a platform for enabling human-centered computing. In this paper, human-centered computing is defined as the development and integration of computational devices and systems that humans interact with, with a human focus, to support human activities (Jaimes et al. 2006).

The aim of the HCPS presented in this paper is to facilitate capturing subjective feedback from vessel occupants along with objective metrics from a ship-based measurement system to provide situational awareness on motion sickness, which is a prevalent and undesired phenomenon on seafaring vessels. The development of HCPSs for seafarers proposes a novel application of cutting-edge technologies with a human-centered approach in a traditionally technology-centered shipping environment. HCPSs in seafaring endeavour to support data-driven decision making on board, gleaning interdisciplinary proficiencies from human-centric approaches in manufacturing and transportation.

In this paper, a synopsis of related work is offered in Sect. 2. An application of HCPSs for seafarers and an architecture for HCPSs in a service-oriented environment are presented in Sect. 3. A case study to showcase human-centered computing in seafaring is described in Sect. 4. An HCPS implementation on board the SA Agulhas II, South Africa’s polar supply and research vessel, is presented in Sect. 5. Results from the case study deployment are provided in Sect. 6, followed by a discussion of the results and HCPS implementation in Sect. 7.

2 Related work

Numerous systems developed for monitoring human behavior are reported in literature, especially to serve the healthcare industry (Lotfi et al. 2020). Data acquisition to monitor human activities and state is achieved with technologies placed on a person directly, by using wearables or mobile devices, or in a person’s environment, for example through machine vision and pressure sensors in a room (Darwish and Hassanien 2018; Lotfi et al. 2020).

CPSs are reported to monitor and aid human activities in areas such as healthcare, manufacturing and smart cities (Bordel et al. 2017; Darwish and Hassanien 2018; Steele et al. 2022). The CPSs are not specifically referred to as HCPSs in the respective papers, but inherently have a human-centric focus. Bordel et al. (2017) integrate people in CPSs as service providers to humanize CPSs and recognize people as more than only physical entities in a CPS. Darwish and Hassanien (2018) recommend human-centered CPS development and see a service-oriented approach as a complementary enabler for CPSs. Steele et al. (2022) highlight that real-time data processing and personalization, which CPSs can offer, are beneficial for healthcare applications.

In a seafaring context, the authors found no HCPS development for monitoring human comfort during ship operation. Techniques to assess human comfort on ships exist, particularly for vessel design or in simulated environments (Tezdogan et al. 2014; Scamardella and Piscopo 2014; Pennino et al. 2020). Human comfort has been investigated on board the SA Agulhas II with data analysis conducted after voyages (Boullé 2016; Omer and Bekker 2018; Bekker et al. 2018; Engelbrecht et al. 2021). Many systems on ships integrate information relating to environmental conditions and vessel performance for operational decision support (Man et al. 2018). In cases where user friendliness and context of use may be considered during system design, the authors observed that humans are regarded as users restricted to the physical layer. Shipboard systems are predominantly reported to be technology-centered, and a human-centered design approach is recommended (Vu and Lützhoft 2020). An onboard wireless system, called ConnectPOB, is available for distress alerting and seafarer location tracking to enhance safety at sea (ScanReach 2022).

3 Human cyber-physical system for seafarers

An HCPS is an extension of a CPS that incorporates human knowledge, behaviors and interactions (Romero et al. 2016; Sowe et al. 2016; Liu and Wang 2020). Through HCPSs, seafarers can be elevated beyond mere users of systems to be part of the cyber layer like other CPSs (Sowe et al. 2016; Yilma et al. 2021). This section presents the Mariner 4.0 concept for seafarers, an architecture for HCPSs and service-oriented CPS environments.

3.1 Mariner 4.0

Taylor et al. (2023) proposed the Mariner 4.0 concept to characterize a human-centric branch of digital developments within digitalization of the maritime industry. Mariner 4.0 aims to represent human factors in digital systems and bridge cyber-physical interfaces likely encountered by a seafarer in a digitalized ship environment. This paper contributes to further development of the Mariner 4.0 concept by demonstrating the deployment of a real-world implementation.

Mariner 4.0 encourages equipping seafarers with virtual counterparts in the cyber layer. Virtual counterparts are envisioned to venture out to sea with their physical counterparts as Mariner 4.0 – a seafarer (passenger or crew member) that is technologically equipped to function effectively in digitalized maritime environments. Furthermore, virtual counterparts for seafarers offer a platform for:

  • Automated integration of human-centric data into decision making by capturing data shipboard, performing data analysis in-situ and displaying relevant information to decision makers.

  • Capturing unique human-related information that can be used in model development to supplement existing models or generate sets of data to support the generation of new models relating to human factors.

  • Facilitating personalized human-cyber interfacing, using individual preferences, abilities and authorizations.

3.2 Architecture for human cyber-physical systems

The foundational elements, and interactions between the elements, that form an architecture of an HCPS are presented in this section. This includes the digital representation and interaction between the cyber and physical entities of an HCPS enabled by an administration (admin) shell for a seafarer.

3.2.1 Admin shell

An HCPS for a seafarer is depicted in Fig. 1. The seafarer is working in a CPS environment where other physical assets, including the camera, smartwatch and motor, have admin shells in the cyber layer. The notion of providing a physical asset with an admin shell, defined as an active representation of an asset (including information regarding the state of the asset) in the cyber layer, is guided by the Reference Architecture Model Industrie 4.0 (IEC PAS 63,088 2017). Equipping a seafarer with an associated admin shell aims to elevate a seafarer from physical entity to CPS status. Each seafarer with their associated admin shell forms an HCPS, referred to as a Mariner 4.0 in this paper.

Fig. 1
figure 1

Architecture of an HCPS

Full size image

Human digital twin solutions are recommended as a promising enabler of virtual counterparts (admin shells) for Mariner 4.0 instances (Taylor et al. 2023). A human digital twin provides a digital representation of a unique individual, which dynamically reflects their state and behavior over time (Bruynseels et al. 2018). Human digital twins may provide an effective means for realizing personalized digital representations and facilitating cyber-physical interactions that admin shells are responsible for.

3.2.2 Personalized digital representation

A core responsibility of the admin shell in the HCPS architecture is to maintain a digital representation that is unique to the associated seafarer. The admin shell could be developed to represent specific variables of the state and behavior of the seafarer as an application requires. For example, if the posture of a seafarer is important to monitor visually, an admin shell could use visualization software to display the movements of the seafarer. Moreover, an admin shell should enable data processing to convert data into information – enriching the digital representation. This processing can include analytic computations to gain deeper insight into the state and behavior of a seafarer. Although real-time reality reflection may be desirable, the digital representation could also be used for estimations of future state and behavior.

3.2.3 Cyber-physical interaction

Admin shells are responsible for facilitating interactions with their associated physical counterpart (shown by the white arrows in Fig. 1), as well as with other admin shells (blue arrows). For seafarers, interaction with their associated admin shell is dependent on support from devices and systems for communicating data and information related to their state and behavior between the cyber and physical layers. Cyber-physical interaction relies on communication channels developed for data and information exchange, which should enable:

  • Transmission of data from the physical layer to the cyber layer. Information relating to physical counterparts, the environment they operate in and interactions in the physical layer are digitized and communicated to the appropriate entities in cyber layer. The desired outcome of this is digitization of the state and behavior of the physical layer, which enables reflection of the physical layer in the cyber layer.

  • Conveyance of information from the cyber layer to the physical layer. Data acquired in the cyber layer that has undergone processing and information received from other entities in the cyber layer are communicated to the physical layer. This aims to inform the physical layer of relevant information gained in the cyber layer.

3.3 The BASE architecture for human integration

Sparrow (2021) and Sparrow et al. (2021b) developed an architecture to facilitate the integration of human workers in Industry 4.0 environments – the Biography-Attributes-Schedule-Execution (BASE) architecture, presented in Fig. 2. The BASE architecture has core components (B, A, S, E and CM) that form a context-neutral framework for an admin shell of a human worker. The core components facilitate plugin components (Scheduling, Execution, Reflection and Analysis Plugins) that can be tailored for application-specific data acquisition, task performance and decision making.

Fig. 2
figure 2

BASE architecture admin shell with generic plugin components

Full size image

The Communication Manager (CM) is the single point of communication with the human admin shell and supports communication between the cyber and physical layers, as well as peer-to-peer cyber layer communication.

The Schedule is a data repository of pending activities to be executed. The Biography is a data repository of past events that also contains correlations and conclusions between data sources that occurred during Execution.

The Attributes component enables a static digital representation, which is composed of persistent information that changes slowly over a long period of time or remains consistent. It is categorized into personal, such as age and gender, and contextual, for example qualifications and job description. The State Blackboard (SBB), in the Execution component, maintains a dynamic digital representation of the human worker, such as their current location or posture. The Execution component is responsible for managing communication related to activities being executed between the human worker and their associated admin shell.

The Scheduling Plugins (SPs) support planning future activities that a human worker is expected to perform in the Schedule. The SPs also support organisational decisions to schedule and optimize scheduled activities based on information in the Attributes, Schedule and Execution. The Execution Plugins (EPs) are responsible for starting and managing the execution of the scheduled activities in the Schedule. The EPs use the Attributes and SBB to support decisions during activity execution and update the dynamic digital representation of the human worker.

The Reflection Plugins (RPs) are responsible for managing the storage of completed activities in the Biography and integrating information gathered after activity completion with the relevant completed activities in the Biography. The Analysis Plugins (APs) update the Attributes based on the analysis of data in Biography entries, thus maintaining and enriching the static digital representation of the human worker.

3.4 Service-oriented cyber-physical system environments

A service-oriented approach is an Industry 4.0 compliant and widely adopted means of enabling communication for data exchange between CPSs (IEC PAS 63,088 2017). Service-oriented CPS environments can effectively facilitate cyber-physical communication for people (Sparrow et al. 2021a). In this paper, a service-oriented approach guides enabling a CPS as a data distribution service provider if the CPS manages data of interest to other CPSs. CPSs that require data from a service provider act as clients that request and receive the relevant data from the service provider. The service-oriented CPS environment can be set up such that admin shells can be service providers or clients, or both.

4 Case study description

4.1 Context and motivation

This case study forms part of a measurement campaign that investigates human and ship responses on the SA Agulhas II (Bekker et al. 2018). Full-scale measurements of the SA Agulhas II position the ship as an ideal test bed for developing software platforms that may benefit operational decisions using data captured shipboard.

The SA Agulhas II can accommodate 50 crew and 100 passengers on annual research and resupply voyages. Participants in previous studies of human factors on board the SA Agulhas II have recorded motion sickness symptoms for consecutive days on voyages, particularly during their first days at sea (Boullé 2016). Motion sickness is known for its debilitating effects on human comfort and is one of the most important parameters used to quantify human comfort due to vessel motion (Mansfield 2005; Tezdogan et al. 2014; Kurt et al. 2016). As motion sickness is occurrent on the SA Agulhas II, with no apparent benefit, it is selected as the human factor of interest for this case study.

The case study focuses on the development of an HCPS for monitoring motion sickness of seafarers to support operational decisions related to human comfort. The data analyzed and generated through the HCPS implementation for monitoring motion sickness was captured on board the SA Agulhas II during the South African National Antarctic Expedition (SANAE) Relief Voyage of 2021/2022. Twelve Mariner 4.0 instances were deployed for data acquisition with passengers on board recruited to participate as physical counterparts to their unique admin shells.

4.2 Objective

The objective of the case study is to demonstrate that the HCPS facilitates human-centered computing on a ship. To this end, the HCPS should provide a digital representation of the state of motion sickness for a seafarer in the cyber layer (through an admin shell) and enable cyber-physical communication between the seafarer and their associated admin shell, as well as with other CPSs, relating to the state of motion sickness. Physical-to-cyber communication focuses on the digitization of the state of motion sickness of a seafarer. Cyber-to-physical communication concentrates on the conveyance of motion sickness related information in the digital representation from the admin shell to the seafarer.

4.3 Motion sickness measurement

Two methods of measuring motion sickness were selected. The first is a generic method based on the knowledge that vessel rigid body motion causes motion sickness (ISO 2631-1 1997). Special processing of vessel motion measurements is used to estimate the severity of motion sickness of seafarers. This approach is classified as an objective method, as the estimate is computed using a standardized procedure that is not personally biased by the seafarer.

The Motion Sickness Dose Value (MSDV) is selected as the metric to quantify a seafarer’s exposure to motion sickness inducing motion due to its widely referenced use for human comfort evaluation on ships (ISO 2631-1 1997; ABS 2021). In the current work, an MSDV is computed for each consecutive five-minute file of acceleration measurements, called MSDV5min, as described further in Sect. 5.3.2. As voyages on board the SA Agulhas II can be weeks long, an equivalent MSDV is calculated using Eq. 1,

$${{\text{MSDV}}_{6{\rm hr}}} = {\left( {\sum {{\text{MSDV}}_{5\min \_i}^2} } \right)^{1/2}},$$
(1)

for each consecutive six-hour window of MSDV5min values to quantify the extended exposure to motion sickness inducing motion (ISO 2631-1 1997).

The MSDV computation is dependent on the frequency weighted vertical acceleration of ship motion, which varies with location on board. To account for the location-dependent exposure to motion, the location of a seafarer on board will be monitored concurrently to motion sickness. The MSDV6hr can then be computed based on a seafarer’s tracked location.

The Illness Rating (IR) is selected to represent the severity of motion sickness due to its widely referenced use to quantify ship motion effects on human comfort and personalized expression of generic motion sickness metrics (Lawther and Griffin 1986; Bos et al. 2007). The IR can be computed from the MSDV using Eq. 2,

$${{\text{IR}}_{\rm objective}} = {{\text{K}}_{\rm m}}\,.\,{\text{S}}'\,.{{\text{MSDV}}_{6{\rm hr}}},$$
(2)

where \({\text{K}}_{\text{m}}\) is a constant that may vary according to the population and \({\text{S}}^{{\prime }}\) is the modified susceptibility to seasickness (ISO 2631-1 1997; Bos et al. 2007). \({\text{K}}_{\text{m}}\) is set to 1/3 for this implementation, as recommended for an unadapted group of male and female adults (ISO 2631-1 1997). A seafarer’s susceptibility to seasickness (\(\text{S}\)) is calculated by Eq. 3,

$${\rm{S = A }} \cdot \left( {{{\rm{e}}^{{\rm{ - }}\frac{{{\rm{y - a}}}}{{\rm{b}}}}}{\rm{ - }}{{\rm{e}}^{{\rm{ - }}\frac{{{\rm{y - a}}}}{{\rm{c}}}}}} \right){\rm{,}}$$
(3)

where y is age in years, A is an amplitude factor depending on history of seasickness and gender, a is the observed age below which little seasickness is seen in experiments, and b and c are time constants expressing observed age dependency of seasickness (Bos et al. 2007). Participants are asked for their age, history of seafaring motion sickness and gender through a questionnaire. The numeric values assigned to the variables in Eq. 3 are presented in Table 1. To get the modified susceptibility to seasickness, \({\text{S}}^{{\prime }}\), \(\text{S}\) is divided by the mean susceptibility for a population (Bos et al. 2007). The mean susceptibility was found to be 0.285 for this study.

Table 1 Numeric values for variables in Eq. 3 (Bos et al. 2007)
Full size table

Seafarers can estimate their own IR (IRsubjective) as well. The IR spans a discrete scale from 0 to 3, where the extreme rating of 0 indicates “I felt all right” and 3 is “I felt absolutely dreadful” (Lawther and Griffin 1986). A seafarer selects an IR that they think corresponds with their motion sickness severity best, which introduces the second method of measuring motion sickness: feedback is captured directly from a seafarer. In this way, a seafarer is equipped to act as a sensor of their own state. This second method is classified as subjective because the value selected is based on an assessment made by the seafarer, which could be influenced by multiple factors, such as their feelings about falling ill.

5 Human cyber-physical system implementation for monitoring motion sickness

5.1 Implementation architecture

The HCPS implementation architecture for monitoring motion sickness is presented in Fig. 3. A single human admin shell associated with a seafarer (called Seafarer 1 in Fig. 3) was developed to form a Mariner 4.0 instance. The BASE architecture was selected to guide the seafarer admin shell implementation as it provides a framework that can be tailored to specific applications and aids the development of admin shells for humans (rather than inanimate assets, which other reported architectures lean towards). An implementation of the BASE architecture was developed in Erlang, a functional programming language. The presented work focused on customizing the BASE architecture implementation and developing context-specific plugins to realize the admin shell for a seafarer, as well as the services required to monitor motion sickness.

Fig. 3
figure 3

HCPS implementation architecture for monitoring motion sickness

Full size image

5.2 Seafarer admin shell development

5.2.1 Personalized digital representation

The BASE architecture accommodates customization of the digital representation in the Attributes and SBB (in Execution). The personal Attributes identified for monitoring motion sickness include a unique identifier, by which to distinguish the seafarer from others (such as a name), age and gender. The contextual Attributes include history of motion sickness while seafaring and susceptibility to seafaring motion sickness.

The selected SBB state variables to monitor motion sickness comprise the metrics required for motion sickness measurement, presented in Sect. 4.3, including location, MSDV5min, MSDV6hr, IRobjective and IRsubjective. These state variables reflect the dynamic state of the environment a seafarer is in (that may contribute to motion sickness incidence) and the individual seafarer’s dynamic physical state.

5.2.2 Plugin development

Following the BASE architecture, plugins that enable motion sickness monitoring, communication between the seafarer and the cyber layer, and construction of the digital representation of the seafarer were developed in Erlang programming language. The functions required to monitor motion sickness and location were mapped to the plugin components in the BASE architecture, as shown in Table 2. The bulk of functionality required to monitor motion sickness can be seen to be allocated to the EPs, which are responsible for handling the data related to the digital representation of the dynamic state of the seafarer on the SBB.

Table 2 BASE plugin function allocation for monitoring motion sickness and location
Full size table

The generic plugins required to perform the functions in Table 2 and that support activity progression through the BASE architecture are presented in Fig. 2. Motion sickness and location monitoring are activities that are scheduled through the activity scheduler SP, which is responsible for inserting activities into the Schedule. Once activities in the Schedule are due, they are started by the activity initiator EP. Motion sickness and location monitoring activities are set to be scheduled when an on board activity is started and stopped when a voyage end activity is started.

5.3 Service implementation and integration

The services required to support the seafarer admin shell in retrieving data from and communicating information to the physical layer, as shown in Fig. 3, were developed. Services to retrieve data on the location, MSDV5min and IRsubjective of the seafarer were required, as well as a service to present information to the seafarer.

5.3.1 Location and IR service

The location and IR service helps equip a seafarer as a sensor of their own state and behavior. A native Android application, called Mariner 4.0, and an Erlang-programmed admin shell were developed to send the location and IRsubjective submitted by a seafarer to their associated admin shell.

The location logging view in the Mariner 4.0 application is shown in Fig. 4a. If a seafarer’s device is NFC-enabled, then they can log their location by scanning Near-Field Communication (NFC) tags that were distributed vessel-wide for this study. If their device is not NFC-enabled, the seafarer can select and submit their location corresponding to the NFC tag locations on a drop-down list.

Fig. 4
figure 4

Mariner 4.0 interface views for (a) location data logging and (b) motion sickness data submission

Full size image

A seafarer can submit their IRsubjective value through the motion sickness data submission view in the Mariner 4.0 application, as shown in Fig. 4b. The IR slider allows the selection of an integer value on a scale from 0 to 3 to correspond with the discrete IR range developed by Lawther and Griffin (1986). The binary class motion sick and vomit questions are additional questions related to this study, but are beyond the scope of this paper.

5.3.2 MSDV service

The MSDV service, developed in Java programming language, aids the computation of the state of motion sickness of a seafarer from shipboard motion measurements. The service should supply the latest MSDV5min based on a seafarer’s location to their associated admin shell. The service receives changes in location as an input parameter from the client (the seafarer admin shell) to ensure that the MSDV metrics based on the most recent location are provided to the client.

In the MSDV service, ISO 2631-1 (1997) motion sickness evaluation analytics relevant to sea travel were used. The assessment process includes: measuring the vertical acceleration that seafarers are exposed to using accelerometers, frequency weighting the accelerometer measurements and computing the MSDV.

Acceleration in the frequency range between 0.1 and 0.5 Hz is associated with the incidence of motion sickness (ISO 2631-1 1997). Acceleration measurements were recorded by five vertically oriented DC accelerometers that are part of a vessel-wide sensor network on the SA Agulhas II (van Zuydam 2021). Two accelerometers are in the forecastle, which represents areas not frequented by passengers near the bow; one is in the bridge, used to represent exposure in passenger accommodation areas; and two are in the steering gear rooms, which are near passenger work areas.

Acceleration measurements were recorded in consecutive five-minute duration batches at a 2048 Hz sample rate. The MSDV service frequency-weights the relevant accelerometer measurements with the motion sickness frequency weighting, Wf (ISO 2631-1 1997), applied directly in the time domain by using a digital infinite impulse response filter (Rimell and Mansfield 2007). The latest MSDV5min is then calculated by finding the Root Mean Square (RMS) value of the frequency weighted signal for the five-minute period (T) and multiplying it by \(\sqrt{\text{T}}\) (ISO 2631-1 1997).

5.3.3 State monitor service

The state monitor service, developed in Erlang, displays motion sickness and location information to a seafarer. A web server, called Cowboy, encapsulated in an admin shell manages the state monitor view, shown in Fig. 5. The last captured IRsubjective and location state variables, computed IRobjective and MSDV6hr, and unique identifier (a name) are presented. The information displayed by the state monitor is based on information supplied by the admin shell of a seafarer. Although user interfaces were developed for seafarers to interact with this service, development efforts were primarily focused on enabling cyber-physical interaction (data exchange), rather than on user interface development.

Fig. 5
figure 5

State monitor view

Full size image

6 Results from case study deployment

Results from two Mariner 4.0 instances deployed on the SANAE Relief Voyage leg departing from Cape Town to arriving in Antarctica, from 3 to 14 December 2021, are presented. The MSDV5min values calculated for four out of the five DC accelerometers are shown in Fig. 6. The values for the port side accelerometer in the forecastle were omitted. The participants of interest did not log their location in this area during the study. The MSDV5min values that were streamed to admin shell of Participant 2 based on their logged location, which is a measure of their instantaneous location-specific exposure to motion sickness inducing motion, are overlayed on the data in Fig. 6.

Fig. 6
figure 6

MSDV6hr values computed for two participants, MSDV5min values computed at accelerometer locations and location-specific MSDV5min values of Participant 2

Full size image

The admin shells of the participants calculated an MSDV6hr for the MSDV5min values received, based on their unique location submissions, over each consecutive six-hour window. This resulted in new MSDV6hr values being computed in five-minute intervals for the two participants, which are also presented in Fig. 6.

An IRobjective value was computed for each MSDV6hr value, resulting in a running IRobjective for each participant, as presented in Fig. 7. Each time a participant submitted an IRsubjective value, the IRobjective value on the SBB and the recently submitted IRsubjective value were fused within a logging activity to record the related objective and subjective metrics together. The IRsubjective and IRobjective that were fused are linked in Fig. 7 with a dashed vertical line.

Fig. 7
figure 7

Subjective and objective IR data for two participants

Full size image

7 Discussion

The SA Agulhas II encountered no noteworthy stormy weather during the leg from Cape Town to Antarctica on the SANAE Relief Voyage in 2021. The trends of the MSDV5min and MSDV6hr values, presented in Fig. 6, display a rise in magnitude on 4 December 2021 that corresponds with vessel departure. The MSDV results show a decrease in magnitude on 10 December, which is when the vessel entered ice. The flattened magnitude of MSDVs until 14 December attests to noticeably less motion sickness inducing motion that seafarers were exposed to during ice passage.

Each HCPS implementation enabled individualized data acquisition and integration from its associated seafarer and the MSDV service. The result of Participant 2’s admin shell notifying the MSDV service of changes in location submitted by the participant is seen in Fig. 6, when the participant exposure marker shifts between accommodation, work and forecastle areas. This ensured that the MSDV5min computed for the accelerometer nearest to the participant’s location was sent to their admin shell, capturing their location-specific exposure to motion.

Participant 2 indicated that they frequented accommodation areas and occasionally visited the work and forecastle areas. The magnitude of motion sickness inducing motion that the participant was exposed to in the work areas and forecastle was notably greater than that in the accommodation areas. The implication of the magnitude difference in the individualized MSDV5min for participants is evident when considering their extended duration of exposure. The equivalent exposure over six hours for two participants, as presented in Fig. 6, was found to be notably different at times, especially between 6 and 8 December. In this time, Participant 1 recorded that they largely spent time in work areas and Participant 2 frequented accommodation areas. This highlights a variation that individualized human-centered computing can account for, particularly regarding human factors like motion sickness that are known to vary greatly among individuals (Mansfield 2005). The MSDV6hr values computed for this study were found to be of similar magnitude to previous motion sickness studies on the SA Agulhas II (Boullé 2016).

In Fig. 7, it can be seen that the IRobjective values underestimated the motion sickness severity when the participants were “slightly unwell” (IRsubjective = 1). Furthermore, unless the MSDV6hr was very near 0 (like during ice traversal), the IRobjective overestimated the severity of motion sickness when the participants felt “all right” (IRsubjective = 0). This paper does not focus on comparing these objective and subjective metrics, but rather on the HCPS functionality as a platform for fusion of related data retrieved from multiple sources. In this case, the objective IR computations of a seafarer’s motion sickness state were fused with the subjective IR feedback from the seafarer to supplement insight into the two methods of quantifying the severity of motion sickness. The values were gathered to deepen insight into seafarer motion sickness state to enhance situational awareness.

In Fig. 7, IRobjective values were estimated in regular five-minute intervals, but the participants comparatively submitted IRsubjective values at sporadic instances. Although seafarers may offer a valuable source of information relating to their own state, it may not always be feasible to equip people as sensors that provide a continuous stream of data. However, it is seen as an advantage that the HCPS can enable different means of quantifying metrics relating to the human state to enrich awareness and understanding thereof.

The presented HCPS provided a platform capable of human-centered computing, which quantified the individual exposure to motion sickness inducing motion guided by standards, estimated the severity of motion sickness in an objective manner and equipped seafarers as sensors to provide subjective feedback on their severity of motion sickness. The HCPS implementation enabled acquisition and integration of data from multiple sources, which relied on network communication between devices distributed (and some mobile) on board. Data security is an important concern, particularly when human-related data is handled. In the presented implementation, efforts towards secure data acquisition and storage were adopted, such as password protected access to devices and data. However, maturation of the implementation to safeguard data transmission is advisable, for example by using cryptography measures. To this end, literature offers frameworks that can guide sensible security design (Jiang et al. 2022).

The HCPS implementation further provided a platform for transforming data captured on board into information regarding seafarer state and behavior. On many vessels, platforms for asset and system monitoring are installed, but no human-centered platform dedicated to monitoring seafarer comfort is reported. Passenger comfort during operation is critical to consider, especially in the cruise industry where comfort may translate into business success. Crew comfort is also vital to consider for task performance, especially in cases where crew sizes are reduced and vessel operational success relies on all members being as effective as possible (Kurt et al. 2016). In the case study at hand, comfort on the SA Agulhas II is important as passengers may be unadapted to vessel motion and living and working on board for several months (Bekker et al. 2018).

A formalized development procedure for HCPSs does not emerge from literature (Liu and Wang 2020). The HCPS for monitoring motion sickness was a case-study-specific implementation realized by developing the elements identified to form an HCPS, guided by the architecture presented in Fig. 1. The admin shell for a seafarer proved to be an effective means of acting as a personalized digital representation of a seafarer in the cyber layer, also facilitating cyber-physical interaction with aid from other CPSs. The HCPS architecture is envisioned to be applicable for developing HCPSs in contexts beyond seafaring, especially in environments where people are expected to interact with systems that have components in both the physical and cyber layers. The development of the presented HCPS architecture and implementation followed systems engineering, human-centered design and service-oriented principles and approaches, which may benefit the development of HCPSs in other contexts as well.

The presented HCPS architecture and implementation demonstrates that the role of a human in an HCPS should not necessarily be limited to either a sensor or a system component. An HCPS can be developed to benefit from receiving data directly from the associated human and supporting the human as an active and essential part of the HCPS. Although a human is physically present in the physical layer, equipping them with an individualized admin shell aims to elevate the human to CPS status. An admin shell can act as a digital representation for a human, which can integrate human-centric models to enrich the digital representation within the admin shell and provide a deeper understanding of the environment a human works in. Additionally, an admin shell can serve as a digital presence that the human can interact with and through in the cyber layer, thereby facilitating human-system integration.

8 Conclusions

This paper presented an HCPS architecture that supports the rationale of supplying humans (present in the physical layer) with associated admin shells (in the cyber layer). In this way, a human can be equipped with a personalized digital representation in the cyber layer to attain CPS status, forming an HCPS. Each person then has their own unique admin shell that is associated with them, which they can interact with directly and interact with other CPSs through.

In the current work, the HCPS realized for a seafarer is called Mariner 4.0. A case study focused on a Mariner 4.0 instance, developed for monitoring motion sickness, was presented. The implementation demonstrated that the HCPS, functioning in a service-oriented CPS environment, performed human-centered computing with operational data captured on board the SA Agulhas II. To this end, the HCPS enabled a platform for:

  • data acquisition and integration from multiple sources, which included seafarers (i.e. humans equipped as sensors),

  • both standardized and personalized computation aimed at quantifying an individual seafarer’s state,

  • customized digital representation of the state of motion sickness and location of a seafarer, and

  • displaying the state of motion sickness and location of a seafarer through a state monitor.

It is regarded advantageous that the HCPS implementation could continuously compute human-centered objective metrics to quantify the state of motion sickness, supplemented with subjective metrics directly obtained from a seafarer. Although the HCPS performed data acquisition and analysis on an individual level, the HCPS implementation was used to obtain results for two participants on the 2021/2022 SANAE Relief Voyage. This highlighted that the HCPS implementation for monitoring motion sickness can be customized for multiple people. Additionally, the comparison of results for the two participants demonstrated variation between individuals that was captured by the HCPS, which may not have been seen if data acquisition was performed at an aggregated level.

Future work includes investigating the concurrent deployment of multiple Mariner 4.0 instances, considering concerns such as scalability and implications on system complexity. The authors envision equipping a group of Mariner 4.0 instances with an associated admin shell (called an aggregate) that maintains their collective information. In this way, operations could be managed with data-driven estimations of comfort levels for a seafaring cohort, at an aggregated and individual level, to leverage productivity and optimize task performance.