An Industry 4.0 architecture for Supply Chain Optimization: A suggested design approach

As the business landscape around us evolves at a rapid pace, organizations that have a vision of the future are scrambling to implement Industrial Internet projects to address the ever-changing business needs. Many businesses are encountering new threats from traditional and emerging competition and they often find that competitors posing the biggest threats to their business are gathering data from smart devices and sensors, analyzing it, and building innovative solutions that enable new business models. The competitors building these solutions gain new business and technical skills and adopt agile development methodologies, enabling deployment of more flexible solutions in faster increments.

In a previous post (link here: Determining Critical Success Factors (CSFs)), I explained how we can use business and usage viewpoints to gather requirements and justification for new projects needed to counter these competitive threats and improve business processes. In this post, I will use a functional viewpoint to explain how to build capabilities you will need in your Industry 4.0 architecture to deliver a solution. It is important that you review the above previous post since the Supply Chain example from that post will be referenced in this post again and again.

I’ll frame this post by describing the five functional domains deployed in IIoT projects as noted by the Industrial Internet Consortium (IIC) (illustration below) in their Architectural Approaches for Success framework For each domain, I’ll also link the domain’s functionality to the requirements identified in our supply chain optimization project in my previous post


Domain 1: The control domain

The control domain denotes the functions taking place in edge devices that serve as industrial controls. These functions include reading data from sensors in the devices, applying rules and logic to create fine-grained closed-loop processing, and providing control over the physical system through actuators. The devices might be networked together or highly distributed and are most often distant from a centralized data store containing historical data gathered from the devices. In the Industrial Internet, they are connected via a network connection back to this central data gathering point.

The following diagram pictures devices in the field (in manufacturing plants, distribution centers, or on transit vehicles in our supply chain example), cloud-based data processing components, and business on-line transaction processing (OLTP) systems and tools. The typical primary components in the control domain are in the shaded area in the illustration below:


Asset management, sensing, actuation, and communication are basic functions that must occur in the edge device for it to be useful. Entity abstraction and modeling might take place in the edge device or in the backend infrastructure (depending on how smart the device is). Understanding network requirements and careful planning here is needed to assure success.

A quick note on selecting sensors and edge devices:

If you are defining a custom solution, you will need to choose sensors and/or the edge devices by matching required functional capabilities you need with those that they provide. Public cloud vendors are making these choices easier by maintaining catalogs of devices proven to work with their footprints and solution offerings. If you are deploying solutions built on applications from an IIoT vendor, you will face less customization and have fewer choices. These solutions usually require specific mandated devices and gateways, thus simplifying the process, though you will have less flexibility in choosing components.

Control domain Applied: The supply chain optimization control domain

You might recall from my post on Gathering Business Requirements, that our stakeholders defined three critical success factors that are the motivation for our supply chain optimization project:

  • Operating factories at maximum capacity (24×7)
  • Delivery of all needed components (parts) to factories just-in-time
  • Maximized revenue from production by meeting product demand

We’ve identified the KPIs that will enable the business to meet these requirements as well in that post. They are required to gather data from the equipment (smart devices) that assembles the products and detects current production status. As these capabilities are embedded in our manufacturing equipment, we’ll need to work with the equipment suppliers on a strategy for gathering the data and transmitting it. We will also want to explore with them the options that we have for taking immediate action if anomalies are detected on the production line.

We also plan to deploy other sensors and smart devices into our manufacturing facilities, distribution centers, and transportation vehicles. The vehicles deliver components containing tagged shipping containers. These sensors and smart devices will enable us to determine supplies on hand, their locations, and likely arrival dates of critical parts in transit, and understand the conditions the parts encountered while in transit.

Domain Two: The operations domain

The operations domain provides life cycle management of the control domain. The scope of management includes device grouping, authenticating and provisioning the devices for service, configuring them (including ongoing updates and applications), and monitoring changing conditions in devices for health, security, and remediation (including retirement). As you might expect, the components underlying the operations domain overlap heavily with the control domain since many of the operations are pushed to the devices. I have illustrated this in the shaded area of the following diagram:


Management of millions of devices is possible today. The devices managed might have varying hardware, software, and messaging protocol characteristics. Identification, logging, and management of devices occurs in the cloud gateway or in an on-premises gateway if the backend infrastructure is not located in the public cloud.

A quick note on device and digital twins 

Device or digital twins refer to a hardware agnostic approach to representing device input, device state, device metadata and device configuration. The use of device twins can shield management of the devices from underlying protocols and can be useful for testing device driven applications in agile development environments.

Operations Domain applied: Supply Chain optimization operations domain

Many of these actions will be critical to the success of the Supply Chain optimization  project we are using in our example. To deliver value to the business, the infrastructure must be well managed and secure. When shortages of critical components or possible damage to those components in transit are detected, we must take appropriate actions to ensure production continues so that key optimization critical success factors can still be achieved. Periodically, we need to issue software and firmware updates to the smart devices to improve their functionality and security.

Domain Three: The information domain

Though some data collection and analysis can take place in the control domain to actuate immediate responses in the edge devices, a much broader and larger data collection and analysis repository is established in the information domain. Here, data can be gathered from multiple control domain locations and from business domain data sources to enable better business operations decision making and to optimize business processes.

In our example, the information domain could be deployed adjacent to control domains in manufacturing plants and distribution centers or on mobile equipment or platforms. The information domain is more commonly established in a central repository in the public cloud or on-premises with the ability also to gather data from back-office business applications.

The following diagram illustrates the information domain in the public cloud as represented by the shaded area:


 A note on Solving information domain functional requirements

The complex nature of this domain causes us to gather many different functionality requirements. These, in turn, result in the evaluation of many diverse components. Among these components are the following ones:

  • Extraction, transformation, and loading (ETL) and data factory tools 
  • Data catalog tools Data management systems (including NoSQL, Hadoop, and relational databases for data warehouses)
  • Analytics and machine learning tools and engines for streaming and persistent data
  • Compute and storage deployed in public clouds and/or on-premises

Information Domain Applied: A supply chain optimization information domain

The list of required functions in our example includes the following:

  • This information domain could introduce a need for many skills that are not present in the company’s IT organization. We’ll need to assess the skills present and begin developing strategies to address those gaps. Typical options considered include skills development through training, hiring consultants to initially provide support, or leveraging the managed services offered by public cloud providers.
  • Data will be ingested from sensors located throughout the manufacturing facilities and in transportation vehicles, and we will be gathering production, location, and temperature data every minute with transmission volume expected to reach 100,000 messages per hour.
  • Some data cleanup will be needed prior to storage and analysis due to incomplete or corrupted transmissions that will occur.
  • The equipment in the manufacturing plants is of various ages and from different vendors, so rationalization of inconsistent data formats will be necessary.
  • The streaming nature of a significant amount of incoming data and the history we will need for more accurate analysis will influence our data management strategy toward inclusion of a Hadoop engine. We expect tens of terabytes of data to be gathered here, growing into the hundreds.
  • As structured data from several existing systems in the business domain will be required as part of the analysis and there is already a data warehouse in place, we will include that in our design.
  • Given data will exist in multiple locations. We’ll create a data catalog to help business analysts find the data and understand its meaning.
  • Alerting is needed if temperature extremes occur or there are anomalies in production that could cause safety concerns driving a requirement for streaming analytics to be part of the solution.
  • We will need to be proactive in protecting our data and require procedures and careful monitoring of data access and encryption of all data.
  • Because this system will be so critical to factory operations, we will include plans for high availability and disaster recovery in all key information domain components.

Domain Four: The application domain

This domain consists of the logic, rules, models, and user interfaces needed to address the business requirements that we gathered previously. The primary components that will comprise an application domain are illustrated in the following diagram:


We will need to reference our discovery documentation and data flow diagrams for our project that were described in the previous post on CSFs. We will also consider how information that is needed will be delivered to the business analysts and other users of the information. For this, we need to assess the skills present among our business users to ensure that we deliver the KPIs and related information in a usable form.

A note on Assessing business analysts and user skills

The kinds of analytics that might be delivered are sometimes designated as follows:

  • Descriptive analytics telling us what happened
  • Diagnostic analytics telling us why an event happened
  • Predictive analytics telling us what will happen
  • Prescriptive analytics guiding us on how to make an event happen

For people working with the data, the skills required are very different in these four categories. Analysts might simply view reports to see what happened. If the analysts want to explore why an event happened, they’ll likely use business intelligence and analysis tools (probably accessible through dashboards). For predictive and prescriptive analytics, they will take on the character of a data scientist, developing applications that include machine learning algorithms.

Delivery of information to business folks making decisions should occur in a format that they easily understand. While some might want to view dashboards, non-analysts who simply want to get their job accomplished are more likely to want a text message or an alert telling them about a significant event and suggesting an action that might be taken.

By understanding our audience and their skills as well as their personal motivation, we can create the right user interfaces. Gathering best practices examples of actions taken in response to events, enables us to establish rules and build the business logic needed as part of our solution.

Application domain Applied: The supply chain optimization application domain

The application domain for the supply chain optimization project will include the logic and rules that performs the functions needed to meet the CSFs. These include logic and rules for our example that do the following:

  • Detect production uptime and rates of products being produced as well as pending parts shortages that will impact the ability to run the factory at capacity
  • Track parts in inventory and parts delivery schedules and then determine if rush orders are needed or second suppliers need to be engaged
  • Track product demand and adjust production rates and inventories as demand for the product changes
  • Match product market promotions to the availability of finished products by location and market opportunity
  • Alert the finance team when product revenue is impacted by supply chain problems

You might notice that these align well with the revenue and cost savings impact of the project that we identified in the previous post on CSFs.

Obviously, the infrastructure we are proposing will be capable of much more. For example, it might be used to enable smarter negotiations with suppliers, gain a better understanding of product quality and the implications of using certain suppliers, and provide better optimization of human and other resources needed to run the factories.

Domain Five: The business domain

In the business domain, we integrate our IIoT project data with data residing in our Enterprise Resource Management (ERP) systems, Customer Relationship Management (CRM) system, and Human Resource Management (HRM) system that run the business. The business domain data sources we will need will align with the business problem we are trying to solve. For example, key ERP modules providing data needed in our supply chain optimization project includes finance (including billing and payment), asset management, Product Lifecycle Management (PLM), Manufacturing Execution System (MES), work planning and scheduling, and Service Lifecycle Management (SLM).

We can broadly classify those ERP, CRM, and HRM systems as Business On-line Transaction Processing Systems, as shown in the following diagram:


Each of these business systems provides specific functionality. We’ll now explore how the data in each can be used to augment the supply chain optimization project that we’ve described:

  • The finance module in the ERP system enables the core financial accounting of the business. It is also used to prepare estimates, send invoices, and accept payments. In our example, it will provide data regarding our financial relationships with our suppliers. This data is often paired with other supplier data (such as on-time delivery records) during contract negotiations. It also provides the product sales transactional data that we will use to understand demand.
  • Asset management enables management of the purchase, deployment, maintenance, utilization, and disposal of inventory and equipment. In our example, it will provide us with the status of the inventory and is also an important source of logistical information.
  • PLM defines a process of managing a product from its beginning to end of life, including engineering design, manufacture, service, and disposal. Our supply chain optimization project will require updates on product manufacturing status and servicing.
  • On the shop floor, the MES is used to schedule, track, and document the processing of raw materials into finished goods. It enables material resource planning and provides metrics on production, equipment efficiency, and quality. These are some of the key metrics we want to track in our supply chain example.
  • Work planning and scheduling applications are used in the arranging, controlling, and optimization of work and workloads during production and manufacturing while accounting for available plant and machinery resources, human resources, and materials. Optimization of production in our plants is something we hope to accomplish in our supply chain optimization example, so these metrics will also prove important.
  • SLM is an application that tracks and manages our field service, including call center management, workforce management and dispatch, parts planning and forecasting, repair and reverse logistics management (returns), and contract management. Our supply chain will be called upon to build replacement component parts for our products based on failure rates that are tracked and predicted.
  • CRM software helps us manage and interact with current and future customers with a goal of improving business relationships that will drive retention and sales. Our ability to ship products on time to our most valuable customers might be a metric that will be tracked as part of our supply chain optimization project.
  • Finally, the HRM system is used in the hiring, training, management, and evaluation of employees. The ability of supply chain specialists to effectively manage the supply chain and get parts delivered just in time might be the evaluation criteria in determining their compensation. In that situation, there would be a HRM element in our project.

Based on experience, education and research- the three essential skills of a knowledge worker.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s