Social Sensors (S²ensors): A Kind of Hardware-Software-Integrated Mediators for Social Manufacturing Systems Under Mass Individualization

Abstract

Currently, little work has been devoted to the mediators and tools for multi-role production interactions in the mass individualization environment. This paper proposes a kind of hardware-software-integrated mediators called social sensors (S²ensors) to facilitate the production interactions among customers, manufacturers, and other stakeholders in the social manufacturing systems (SMS). The concept, classification, operational logics, and formalization of S²ensors are clarified. S²ensors collect subjective data from physical sensors and objective data from sensory input in mobile Apps, merge them into meaningful information for decision-making, and finally feed the decisions back for reaction and execution. Then, an S²ensors-Cloud platform is discussed to integrate different S²ensors to work for SMSs in an autonomous way. A demonstrative case is studied by developing a prototype system and the results show that S²ensors and S²ensors-Cloud platform can assist multi-role stakeholders interact and collaborate for the production tasks. It reveals the mediator-enabled mechanisms and methods for production interactions among stakeholders in SMS.

1 Introduction

Today’s manufacturing has been heading towards mass individualization with the characteristics of time-varying market, various customer requirements, customer participation for value embodiment, and high flexibility of manufacturing and services. A cyber-physical-social- connected and service-oriented manufacturing paradigm called social manufacturing [1,2,3] is proposed to adapt to the mass individualization environment. It tackles the complexity, flexibility, scalability, and interoperability of collaborative individualized production, by aggregating socialized manufacturing and service resources from micro-/small-/medium-sized enterprises, smart factories, workshops, and even scattered individuals for work in an autonomous, self-organized, and plug-and-use way. Under social manufacturing paradigm, traditional manufacturing systems should be transformed into social manufacturing system (SMS) which has a flexible and platformized organization structure. SMS dynamically integrates materials, humans, and equipment from different production participants, transforms raw materials into individualized products in high flexibility and efficiency with the inside loop of planning, execution, control, and feedback. Besides, it handles the outside socio-technical factors (e.g., specific social and political forces, evolution of information and communication technologies–ICTs, human labor costs), market demands towards high product individualization, and others via social interactions.

Satori [4] thought that it is not the technical factor that keenly affects profit in manufacturing systems but the organization structure factor. The flexible and platformized structure of SMS adapts to the current trends and will improve the profit in SMS. Under this structure, SMS can be viewed as a kind of Cyber-Physical-Social System (CPSS) [5, 6], which builds the heterogeneous networks of things, data/information, services, and humans from the cyber, physical, and social perspectives, by applying the emerging ICTs, such as RFID/IoT, cyber-physical system (CPS), Big Data, social networking, and mobile Internet [7]. From another view of point, SMS facilitates the vertical and horizontal integration of businesses throughout the value networks. The systematic architecture of SMS can be described in Figure 1. In the SMS, the service demanders can be customers, traditional manufacturing enterprises, outsourcers/crowdsourcers, and new-born firms/SMEs [8, 9], while the service providers can be all kinds of enterprises, firms, workshops, and individuals. The complex outside factors affect SMS dynamically, which needs certain supporting mechanisms to keep it operating normally. For example, the resource self-organization and management mechanism enables all the production participants (customers, service demanders, and service providers) to interact and collaborate autonomously for common goals. The risk evaluation mechanism assesses whether SMS can handle the dynamic changes well. The supporting hardware and software provide tools for SMS to execute cross-enterprise production tasks.

Figure 1

Systematic architecture of SMS

As to the implementation of SMS, different production participants make up a collaboration network for production tasks. Thus, inter-enterprise production interaction becomes the key factor for efficient execution, due to the characteristic of multi-role participation in production. To realize it, two problems should be dealt with: ① the hardware-software-integrated mediator and platform for inter-enterprise production interaction should be designed and configured; ② the operational logics of inter-enterprise production interaction should be clarified.

In this paper, from the sensing and interaction point of view, Social Sensors (S²ensors) are developed for SMS to form the application base for production interactions during the individualized production processes. Specifically, S²ensors are a kind of hardware-software combinations that can sense real-time social interaction data from humans and machines, and merge data into meaningful information for production decision-makings. Based on the cloud technology, S²ensors are incorporated into an open platform, forming the S²ensor-Cloud. Based on that, the vertical and horizontal interconnection/integration of data, information, services, humans, and things (machines, equipment, tools, etc.) are realized. Except for that, the operational logics of inter-enterprise production interactions are addressed. Production participants perform their businesses with the right objects in the right time by applying S²ensors.

The rest of this paper is arranged as follows: Section 2 reviews the related work on manufacturing systems and production interaction and coordination. Section 3 clarifies the concept of S²ensors, including definition, components, classification, operational logics, and formal description. Section 4 describes the S²ensors-Cloud platform and its systematic architecture. A demonstrative case is described in Section 5 to illustrate the application of S²ensors and S²ensors-Cloud platform, together with the operational logics of inter-enterprise production interactions for outsourcing production. Finally, discussions and conclusions are given in Sections 6 and 7, respectively.

2 Related Work

2.1 Manufacturing Systems

Mourtzis and Doukas [10] summarized the evolution of manufacturing systems from craftsmanship to the era of customization, and described the concepts, applications, benefits and drawbacks of mass production and mass customization. Previous manufacturing systems can suit for mass production and mass customization, which mostly focus on the intra-enterprise production control and management. The assembly lines are a kind of manufacturing system for mass production, while the reconfigurable manufacturing system (RMS) and decentralized manufacturing system (DMS) are a kind of manufacturing systems for mass customization. Koren and Shpitalni [11] discussed the design, configuration, and deployment principles of RMS in detail. They revealed that the capacity and functionality of RMS could be changed exactly when needed, meantime be efficiently utilized in a lower cost for dynamic requirements. Mourtzis and Doukas [12] discussed the trends, challenges, and outlook of DMS. They pointed out that DMS facilitates the inter-enterprise collaboration and offers many advantages towards supporting the turbulent mass customization environment. That indicates DMS has started to focus on the inter-enterprise production interaction and coordination. In today’s mass individualization environment, social manufacturing paradigm has become the trends. More dynamic market and individualized requirements should be dealt with. Thus, SMS should be developed to have superiority in the characteristics of flexibility, scalability, and interoperability than previous manufacturing systems.

From the view of control structure of manufacturing systems, the centralized control is adopted for mass production. All the production commands and instructions are transmitted to different workstations from the common centralized control center, and all the data flow from bottom machines and tools are uploaded to the centralized database for data processing [13]. However, as the evolution of ICTs, together with the fast-moving market and individualized requirements, the centralized control structure has been unsuitable for SMS. A cloud-based, decentralized, and self-organized control structure should be developed for SMS. The units in SMS should have the capability of high intelligence, autonomy, self-organization, and dynamic reconfiguration. Thus, the inter-enterprise production interaction will meet with new situations.

2.2 Production Interaction and Coordination

To keep manufacturing systems operating regularly, the interaction and coordination among different production participants should be settled. Production interaction deals with the customer requirements, production state monitoring and feedback, production control and management, etc.

To facilitate inter-enterprise production interaction and coordination, fundamentals for interaction and coordination should be firstly dealt with, including hardware-software-integrated infrastructure and interaction mechanisms. In the infrastructure aspect, Chung, et al. [14] proposed a scalable and flexible MULtimedia-support Social Web of Things platform (MUL-SWoT) to integrate smart objects and 3rd party service providers for interactions. Yuriyama and Kushida [15] proposed a Sensor-Cloud infrastructure to virtualize physical sensors on the cloud computing. Needed sensors are dynamically grouped for sensor services, which can facilitate human-to-machine interactions. Viswanathan, et al. [16] discussed a cyber infrastructure that builds an open space and platform for consumers, designers, manufacturers, and others to participate in personalized production. The production interactions among them are enabled by the integration of different information systems in the cyberinfrastructure. Ding and Jiang[5] stressed the interconnection of physical objects, humans, data/information, and others, which generates a ubiquitous manufacturing environment and makes production interactions easy, targeted, and efficient. In the interaction mechanism aspect, Hsieh, et al. [17] discussed a service interaction mechanism to help enterprises systematically manage customers’ expectations in dynamic interactions. Core enterprises are provided with timely and relevant information to enable them make informed decisions or complete work easily. Guercini and Ranfagni [18] discussed buyer-seller interaction mechanisms in facility services from some empirical case studies. The empirical results proved that interactions between buyer and seller are vital when outsourcing business services. Borangiu, et al. [19] discussed the distributed manufacturing control with extended contract net-based protocol (CNP) interactions. The proposed method focused on the interactions between intelligent products and machines. Ong, et al. [20] addressed the augmented assembly technologies based on 3D bare-hand interaction. It showed possible industrial implications of augmented reality in human-to-machine interactions. Wan, et al. [21] discussed the context-aware vehicular cyber-physical system in intelligent transportation that combines social network for interactions.

From the literature above, it can be found that human-to-human interaction, human-to-machine interaction, and machine-to-machine interaction are separately discussed. While in manufacturing domain, little work integrates them for the whole process of individualized production. Thus, a wider range of ubiquitous manufacturing environment and infrastructure at both intra-enterprise and inter-enterprise level should be built. In this work, S²ensors and S²ensors-Cloud platform for SMS are proposed to deal with that.

3 Clarification of S²ensors

3.1 Definition

Definition 1

S ² ensors are defined as a kind of software-hardware-integrated mediators that firstly observe input data from human-to-human, human-to-machine, and machine-to-machine interactions during individualized production processes, then merge the input data through embedded algorithms and methodologies, and finally return meaningful interaction results (output). An S²ensor can be viewed as an integration of physical sensors (hardware) and non-physical detectors (software applications). Thus, S²ensors can be formalized as

$$\begin{aligned} S2ensors:: = \{ id,Type,vTime,seCons,Para, \\ Cap,Cont,His,Com\} , \\ \end{aligned}$$

(1)

where the properties of S²ensor describe the Unique Resource Identifiers (URI), classification type, valid working time, data security constraints, feature parameters, capabilities, owner’s information, historical events, and function components, respectively.

The social feature of S²ensors exists in two aspects: (1) S²ensors are socially distributed around the world (existing everywhere); (2) S²ensors have social interaction abilities with others. Especially under the tide of mobile Internet and social networking, interconnection is enabling, and sharing is achieving. S²ensors play an important role in interconnection and sharing, they provide ubiquitous sensing and processing services of behaviors, environment, capabilities, commands, and states for human-to-human, human-to-machine, and machine-to-machine interactions in SMS.

With the help of S²ensors, requirement data from customers, production commands from enterprises, and industrial data from machines can be captured and shared. Therefore, the interaction relationships among them become closer and the production coordination among them becomes efficient.

3.2 Components

In analogy to the traditional physical sensors, an S²ensor should have five components, i.e., sensing unit, pre-processing unit, application unit, transferring unit, and assistant unit, as shown in Figure 2.

Figure 2

Components of S²ensors

Sensing unit proactively crawls subjective social data and objective sensor data. The subjective social data are derived from mobile Apps (e.g., social media) installed in S²ensors, while the objective data are achieved from physical sensors (e.g., GPS, camera) embedded in S²ensors. Here, compatible application program interfaces (APIs) are developed to integrate relevant software (mobile Apps) and hardware (physical sensors) for data collecting.

Pre-processing unit performs data checking of errors and duplications, and further normalizes the collected raw data in a standard and easy-transfer format. The duplicated data and the duplicated times are logged, which shows the importance degree of data. Then the subjective data and the objective data are formatted in JSON for easy transferring. Besides, it borrows a local data storage cache to cope with the intermittent connectivity. Thus, S²ensors can synchronize the data whenever connectivity is available. Actually, pre-processing unit acts as a kind of middleware to pre-process the collected raw data.

Application unit applies algorithms and methods such as Big Data Analytics, Support Vector Machine (SVM), data clustering, and statistics analysis method to merge the pre-processed data into meaningful information for data services. These algorithms and methods are embodied in the form of function modules or applications in middleware. Based on the application unit, some decisions can be made autonomously by the S²ensors, which enhances the self-organization and self-control characteristics of S²ensors during the individualized production.

Transferring unit transfers the formatted data, information, commands/instructions, and others needed from one S²ensor to other S²ensors for interoperability and reaction or to the cloud database for further processing under certain data interfaces and network protocols, such as HTTP, TCP/IP, SOCKET, and Fieldbus.

Assistant unit provides the above four components with assistant services, such as power, screen, and data storage. It should be pointed out that when packaged with certain software applications, the screen can act as the human-machine interface (HMI), it provides a direct way for humans to input their feelings, commands, and other data into the S²ensors for interaction and processing, and the processing results can be further displayed to humans.

Note that each S²ensor is configured with a URI in Internet, which enables them accessible to others under certain authority. All the S²ensors form a global S²ensor- Cloud for interconnection, sharing, and interoperability. Besides, different S²ensors can aggregate into a social community autonomously for further seamless interaction and authorized sharing.

3.3 Classification and Operational Logics

According to the type of interaction objects, S²ensors can be classified into three kinds, i.e., HH-S²ensors, HM-S²ensors, and MM-S²ensors.

3.3.1 HH-S²ensors

Definition 2

HH-S ² ensors deal with the human-to-human social interactions and the social data collecting during individualized production, such as interactions among customers, interactions between customers and enterprises, and interactions among enterprise’s staffs.

Thus, HH-S²ensors are applied at both the inter-enterprise level and the intra-enterprise level. The difference exists in the social contexts of the inter- and intra-enterprise interactions. Smart mobile terminals (e.g., smartphones, tablets, wearable devices) with installed mobile Apps can be viewed as a concrete instantiation of HH-S²ensors. The enabling technologies for HH-S²ensors-based interaction include social computing, big data analysis, and so on. Take the production interactions between customers and enterprises as an example. The operational logics of HH-S²ensors can be described as follows (see Figure 3):

Figure 3

Operational logics of HH-S²ensors

• Customers interact with enterprises via social media in HH-S²ensors (smartphones) to express their feelings, intentions, and requirements;

• These objective data together with the subjective data (e.g., longitude and latitude, camera) are analyzed into meaningful information and transferred to the HH-S²ensors of enterprises;

• Meantime, HH-S²ensors of enterprises collect and process their objective data and subjective data into meaningful information and transfer them to customers.

Based on that, the production decision-makings and market prediction are collaboratively made by enterprises and customers.

The operational logics of HH-S²ensors application in other human-to-human interaction situations are similar. It should be pointed out that smart mobile terminals are just a kind of HH-S²ensors, the concrete instantiations of HH-S²ensors are not limited to the smart mobile terminals. There can be many other kinds of HH-S²ensors with the above functions and features. Two ways can be used to create HH-S²ensors: ① create new kind of software-hardware-integrated devices as HH-S²ensors; ② upgrade the current software-hardware-integrated devices and endow them with HH-S²ensors’ functions. The first way is expensive while the second way is cost-effective and with high applicability, as the amount of mobile devices has been increasing exponentially in people’s life.

3.3.2 HH-S²ensors

Definition 3

HM-S ² ensors deal with the human-to-machine interactions and the physical data sensing during individualized production. Through HM-S²ensors, humans can efficiently interact with machines, assign production tasks and commands to machines, and receive feedback from them. Human-Machine Interface (HMI) or Human-Computer Interface (HCI) is a concrete instantiation of HM-S²ensors. HMI/HCI enabled by virtual/augmented reality, embedded computation, cognitive computing, and artificial intelligence facilitates learning and control of devices for enhancing individualized product design and manufacturing operations. Take the HMI/HCI application in individualized product design phase as an example. The operational logics of HM-S²ensors can be described as follows (see Figure 4).

Figure 4

Operational logics of HM-S²ensors

After enterprise receives customer’s requirements, it will translate these requirements into engineering features and indicators. Based on that, enterprise’s designers interact with their design tools (embedded with HM-S²ensors);

Design commands and instructions from designers are assigned to design tools via HM-S²ensor-based interaction;

HM-S²ensors on one hand crawl the actions and movements of designers in the augmented reality environment (e.g., through bare hand interface) [17], and on the other hand receive sensory input, such as text, video, and graphics from designers that indicate their ideas, intentions, and feelings;

Through these human-to-machine interactions, the individualized product design processes are efficiently solved. The final product scheme is presented in the augmented reality environment and further transferred to customers for evaluation.

HM-S²ensors-based interactions in manufacturing operations are similar to that in the product design phase. Production commands are transmitted from operators to machines through HM-S²ensors. HM-S²ensors at the machine end collect their real-time operating data and merge these data into operating state information to give suggestions to operators’ production decisions. Cyber-Physical System (CPS) Units can also be viewed as a kind of HM-S²ensors at the machine end. There are also two ways (upgrading and creating) to create HM-S²ensors, which are similar to the HH- S²ensors.

3.3.3 MM-S²ensors

Definition 4

MM-S ² ensors deal with the machine-to-machine interactions and the physical data sensing during individualized production. Through MM-S²ensors, machines can socially interact with each other to react autonomously to unexpected events, make collaborative production decisions, and upload the execution results to the management center. CPS Unit can be viewed as a concrete instantiation of MM-S²ensor. It consists of physical sensors to sense machine-related data (e.g., vibration, energy, speed, displacement) and ambient data (e.g., temperature, humidity, noise), actuators responsible for the execution of production commands, and functional applications to process data and make decisions. The operational logics can be described as follows (see Figure 5).

Figure 5

Operational logics of MM-S²ensors

After machine fleet receives dynamic production commands, they start to interact with each other. Each MM-S²ensor senses real-time data from its responsible machine, such as working state, current task, ambient temperature /humidity;

Based on the objective of global optimum, production commands are allocated to optimal machines after interactions among MM-S²ensors have been settled;

During the production commands execution phase, dynamic adjustments may be made if disturbances occur. Thus, coordination among MM-S²ensors is periodically made according to real-time data.

Note that the most important thing to facilitate interactions among HH-S²ensors, HM-S²ensors, and MM-S²ensors is that a cloud-based cyber-physical-social network should be built. This network integrates wireless personal area network (WPAN), local area network (LAN), and wide area network (WAN) at both the intra-enterprise and inter-enterprise levels from cyber, physical, and social perspectives. Social interactions, which are inherently non-linear, may lead to order and division of S²ensors within groups. The behavior of target S²ensor is determined by the interaction contexts and environmental stimuli. S²ensors are not fixed in the tasks that they perform, but they switch in response to changes in time.

Except for the above classification method, from the view of input/output data type, S²ensors can be classified into 9 kinds [5]. The input data of S²ensors include: 1) social context generated from human-to-human social interaction; 2)customer requirements transferred from customers’ input text; and 3) physical sensor data derived from physical sensors embedded in the S²ensors. The output data of S²ensors include: 1) social data; 2) command/event; and 3) control signal. Different combinations of input/output data type create different kinds of S²ensors, as shown in Figure 6.

Figure 6

Classification of S²ensors based on input-output type

Mention that the differences between social data and physical sensor data can be concluded as two aspects: 1) social data is the second-hand data derived from raw input data processing while physical sensor data is the first-hand input data; and 2) social data is human-induced data and reflects the social interactions among humans, while physical sensor data is human-independent data and embodies the status monitoring of S²ensors and machines. Referring to the relationships of these 9 types of S²ensors and HH-S²ensors, HM-S²ensors, and MM-S²ensors, type 1, 2, 3 can be mapped into HH-S²ensors, type 4, 5, 7, and 8 can be mapped into HM-S²ensors, and type 6 and 9 can be mapped into MM-S²ensors.

In some sense, S²ensors bridge the gap between the physical space and the social space, with the aid of emerging cyber technologies. To a broader sense, when equipped with S²ensors, products (or raw materials) become smart products. Through social interactions with S²ensors-equipped machines, humans, and others, they can know how they are produced, where they come from and where they will go, and which machine they need to produce themselves. Thus, an autonomous, self-organized, and self-controlled production way is formed to efficiently produce individualized products. Meantime, dynamic requirements and production disturbances can be solved in time through S²ensors-based production interactions.

3.4 Formal Description Language – S²ensorML for S²ensors Modeling

Most physical sensors are distributed and are built on certain sensor platforms. Their applications rely on the hardware and transmission protocols, which is difficult for inter-platform discovery, access, and processing. Thus, sensor data cannot be fully shared.

Under mass individualization, distributed multi-source heterogeneous S²ensors need to be virtualized and formalized for discoverability, interconnection, and data interchange, sharing, and processing. The eXtensible Markup Language (XML) schema can be used to publish formal descriptions of the sensor’s location, capabilities, interfaces, protocols, and other attributes. Sensor Model Language (SensorML) Standard is based on XML and it provides an information model and encodings that enable discovery and tasking of Web-resident sensors and exploitation of sensor observations [22]. SensorML can be used to describe a wide range of sensors, including both dynamic and stationary platforms and both in-situ and remote sensors [23].

However, there are no functions or mechanisms defined in SensorML to describe the social interactions between sensors. Besides, SensorML mainly deals with objective data collecting and processing, and it seldom handles the subjective data from social interactions. In this paper, we borrow the principles from SensorML, and propose a formal description language called S²ensorML to describe the metadata and functions of S²ensors in the inter-enterprise production interaction scenarios. S²ensorML focuses on the function model of S²ensors, not just the hardware description model. The most important concepts in S²ensorML include S ² ensor, Process, AggregateProcess, and ProcessMethod. Specifically, ProcessMethod in S²ensorML includes the methods and algorithms for social interactions, while not in SensorML. Other relevant definitions can be found in Ref. [22].

Definition 5

Process is defined asan operation that takes one or more inputs, and based on a set of parameters, relevant metadata, and methodologies generates one or more outputs for discovery and human assistance.

Processes described in S²ensorML are discoverable and executable. Within S²ensorML, physical sensors are all modeled as physical processes that can be connected, while the mathematical operations or functions in the software applications can be modeled as non-physical processes. In all, the input-processing-output (IPO) procedures whether physical or non-physical can be viewed as processes.

Definition 6

AggregateProcess is defined as a set of interconnected processes or aggregate processes themselves with an explicit mapping of the input-output data flow between these processes.

It is clear that an AggregateProcess can be viewed as a process network or process chain. AggregateProcesses are themselves processes with their own inputs, outputs, and parameters.

Definition 7

ProcessMethod is defined as the algorithms, behaviours, and interfaces of a Process, especially for the social interaction functions, such as big data method, data fusion, and clustering algorithm.

The UML models of S ² ensors, Process, AggregateProcess, ProcessMethod, and their relationships are described in Figure 7, in which the properties of each concept are listed. The detailed explanations of these properties can be found in Ref. [22]. Specifically, AggregateProcess has the properties of components and connections, which indicates the component processes making up the AggregateProcess and the connection relationships among these component processes. Based on the UML models, the XML schemas can be automatically generated by applying the standard UML to XML schema encoding rules. Here, we omit it for simplicity.

Figure 7

UML model and relationships

S²ensorML addresses the discovery of S²ensors, acquirement of S²ensor’s attributes and behaviors, description of S²ensor’s workflow, and processing of S²ensor data. Besides, S²ensorML enables the development of plug-and-play S²ensors and processes, which may be seamlessly added to SMS for decision-making support. The S²ensorML-based S²ensors also support the development of an autonomous S²ensor network for SMS where S²ensors can interact with each other and publish alerts and tasks to which other S²ensors can subscribe and react.

4 S²ensors-Cloud Platform for SMS

4.1 Overview of S²ensors-Cloud Platform

In SMS, inter-enterprise production interactions happen frequently. Thus, heterogeneous S²ensors need to be virtualized, and their data should be shared with different production participants. Public S²ensors-Cloud based on cloud computing is a feasible solution. Different S²ensor owners register their S²ensors to the cloud, forming the S²ensors-Cloud when combined with social networks. Furthermore, dynamically self-organized S²ensor communities (i.e., private S²ensors-Cloud) are generated for different SMSs, providing various services via social interactions and authorized sharing. When production tasks are finished, SMSs and S²ensors communities are dissolved. The functions of S²ensors-Cloud platform provided by the 3rd party service provider include:

• Provide a way to virtualize and register S²ensors to the cloud platform;

• Combine social networks and communication interface mechanisms for human-to-human, human-to-machine, and machine-to-machine social interactions and information/command exchanging.

Dynamically self-organize into S²ensor communities for authorized sharing;

4.2 System Architecture of S²ensors-Cloud Platform for SMS

This section presents the system architecture of S²ensors-Cloud platform for SMS. It consists of three key elements performing different roles, including S²ensors at the physical layer, public platform at the cyber layer, and S²ensors-Cloud at the social layer, as shown in Figure 8.

Figure 8

Architecture of S²ensors-Cloud platform for SMS

At the physical layer, HH-S²ensors, HM-S²ensors, and MM-S²ensors are equipped to humans and machines. These S²ensors are capable of collecting and processing real-time data, interacting with others, and reacting to transmitted production commands in an authorized plug-and-play way. All the S²ensors are mapped into virtual nodes via registration and virtualization. At the cyber layer, public S²ensors-Cloud platform provides functions, application tools, cloud databases, and network access for humans and machines to communicate with each other. The information generated from social interactions is stored in the cloud database with different authorities for further processing. The event subscription and publish mechanism enables the data be periodically or event-triggered collected during social interactions. Different Application Program Interfaces (APIs) offer ways to link functions from other platforms and systems.

Of notable, the RESTful API-based gateways [24], as a Web server, abstract the communications between S²ensors and the public S²ensors-Cloud platform. The ubiquitous network connectivity assigns a URI for each S²ensor in the platform and enables them accessible to others.

The SMS and S²ensors-Cloud make the organization structure of individualized production flat and platformized, which relies on the social interactions via S²ensors and improves the response ability to dynamic requirements.

5 Case Study

5.1 Case Initialization

After clarifying the S²ensors and the S²ensors-Cloud platform, we give a demonstrative case of S²ensors-Cloud-based production interactions in SMS in this section to verify the proposed model.

Assume that EA is a core enterprise (customer), EB and EC are two manufacturing enterprises (service providers), undertaking outsourcing tasks from EA. The managers of EA, EB, and EC are equipped with HH-S²ensors and HM-S²ensors. EB and EC both have two machine tools, all of which are equipped with HM-S²ensors and MM-S²ensors. The production participants including S²ensors, enterprise managers, machine tools, and other assistances make up a self-organized SMS for individualized production. Here, we omit the partner selection of EB and EC because there are existing mechanisms such as contract net-based or bidding-based methods. They can be directly imported to the S²ensors-Cloud platform.

5.2 Contextual Description of Production Interactions in SMS

The production interaction contexts can include customer requirement exchange, production commands transmission, production state uploading, production task reallocation, etc., which are related to different participant couples.

Scenario modeling method based on message sequence chart (MSC) is adopted to describe the production interactions in SMS, as shown in Figure 9. Two key elements in MSC are the instance and the message flow. In Figure 9, seven instances (i.e., S²ensor of EA, S²ensor of EB, S²ensor of EC, S²ensor of EB’s machine 1 and 2, and S²ensor of EC’s machine 1 and 2) are included. The message flow among them is illustrated according to the actual sequences of production interactions. The messages are triggered by different events, such as dialog initialization, message sending event, message receiving event, timer. In Figure 9, the multi-role interactions during individualized production can be described as follows.

Figure 9

Contextual description of production interactions in SMS

EA releases production tasks to EB and EC through HH-S²ensors;

EB and EC receive real-time data from their machines periodically through HM-S²ensors, based on which they can allocate appropriate amount of tasks to their machines;

During individualized production, MM-S²ensors collect the state data of EB’s machine 1 and 2 (and EC’s machine 1 and 2) in real-time, based on which they can coordinate and react to the unexpected events. For example, if machine 1 breaks down, machine 2 will take over its tasks after interaction;

If changes need to be made, EA will describe its dynamic demands, intentions, and feelings through HH-S²ensors. After receiving these sensory input data and relevant objective data in HH-S²ensors, EB and EC will process these data into engineering requirements by applying HH-S²ensors;

After that, EB and EC interact with their machines to adjust the production commands through HM-S²ensors;

Finally, finished products are delivered from EB and EC to EA.

It can be seen that S²ensors-Cloud platform integrates different kinds of S²ensors, and they self-organize into private S²ensors-Clouds for lifecycle production interactions in SMS. Through human-to-human, human-to-machine, and machine-to-machine interactions, the individualized production processes become transparent to customers and enterprises, and the inter-enterprise production coordination becomes close-loop controlled.

6 Discussions

In this paper, we discuss SMS in individualized production environment. To facilitate multi-role and multi-level production interactions in SMS (Figure 9), S²ensors are defined and imported into the SMS. Based on that, seamless human-to-human, human-to-machine, and machine-to-machine interactions are enabled.

However, this paper just clarifies the S²ensors and S²ensorML-based formal description. When applied in production interactions, two other issues need to be solved.

6.1 Inter-enterprise Production Commands System

Under mass individualization, production commands and interaction contexts may be transmitted to machines from enterprise managers, or other machines, even the customers. For easy understanding and communication, the formal description of production commands becomes important. Thus, an inter-enterprise production commands system should be developed to support the inter-enterprise production control. In all, production commands definition and classification, data transfer and sharing mechanism, and data interfaces and specifications for interoperability are key problems need to be further discussed.

6.2 Hybrid Distributed Control Architecture of SMS

A hybrid distributed control architecture should be addressed in our future work, which is built on the “sense-action” mapping and event triggering mechanism. It should have three layers, including human-to-machine interaction layer, machine-to-machine interaction layer, and autonomous execution/control layer. This architecture will enable SMS execute commands efficiently with a global optimum and response quickly to production disturbances.

Other key technologies, such as self-organization-based task allocation mechanism, Web Ontology Language (OWL)-based data interchange, Semantic Web-based web information processing, data authentication and authorization, and development technologies of S²ensors-Cloud platform, should be further discussed.

7 Conclusions

• (1) A kind of hardware-software-integrated mediators called social sensors (S²ensors) is proposed for social manufacturing system under mass individualization;

• (2) XML-based formal description of HH-S²ensors, HM-S²ensors, and MM-S²ensors is studied to deal with human-to-human, human-to-machine, and machine-to-machine interactions, respectively;

• (3) An S²ensors-Cloud platform is developed to integrate different kinds of S²ensors and make them work in an autonomous way. This platform is based on cloud technology and self-organizing method;

• (4) A private S²ensors-Cloud around the certain production task is formed, which facilitates the production interaction and coordination in SMS;

• (5) Future work should be devoted to the application of S²ensors and S²ensors-Cloud, which is a systematic work to leverage the mass individualization.