Smart Manufacturing Systems

01Purpose and scope

• This manual supports the course Smart Manufacturing Systems. It describes how practitioners plan, connect, operate, and improve production systems that collect data from machines, route work orders, and feed decisions made by people and software. It is written as a working reference for plant engineers, controls technicians, production supervisors, and analysts who are asked to make a line or a site measurably more responsive.
• The scope covers discrete and batch manufacturing on a single site or a small group of sites. It touches machine connectivity, data collection, manufacturing execution functions, scheduling inputs, quality data capture, and the governance around them. It does not cover product design, supply chain network planning, or enterprise financial systems, although those systems exchange data with the factory and are discussed where the handoffs matter.
• Practice changes with the plant. A brownfield site with mixed-age controllers, paper travelers, and a legacy historian faces different constraints than a greenfield cell built around current industrial protocols. A high-mix job shop values flexible routing and fast changeover data, while a high-volume automotive or electronics line values cycle-time stability and traceability. The same methods apply, but the priorities, budgets, and acceptable risks differ, and this manual points out those differences where they change the recommended action.

02Core principles

• Start from a decision, not a technology. Every sensor, connection, and dashboard should answer a question someone on the floor or in planning needs answered, such as why a press stopped, which lot is affected by a material deviation, or whether a changeover is taking longer than the standard. Systems built around vague goals like having more data tend to produce dashboards nobody reads and databases nobody trusts.
• Treat the data model as the real product. Tags, units, timestamps, machine identifiers, and status codes must be defined consistently before large volumes move. A temperature recorded in Fahrenheit by one controller and Celsius by another, or a downtime reason typed freely by each shift, makes every later analysis unreliable. Agree on naming conventions and code lists early, and assign an owner to each.
• Keep control functions and information functions separate. Real-time machine control stays with programmable logic controllers, drives, and safety systems designed for that purpose. Higher-level systems such as a manufacturing execution system or an analytics platform read and write information and recommendations, and they should not sit in the critical path of a machine safety function. The ISA-95 (IEC 62264) model is a common reference for drawing the boundary between enterprise, operations management, and control levels.
• Design for the operator. A system that adds clicks, login steps, or redundant entry will be bypassed under production pressure. Operators who see their own input used to solve their own problems will keep the data clean. Involve them in screen design and in testing before rollout.

03Planning and preparation

• Begin with a short baseline study of the process as it actually runs. Walk the line, interview operators and maintenance staff, and record where time, scrap, and information are lost. Gather existing sources: machine logs, shift reports, maintenance tickets, quality records, and spreadsheets that someone maintains by hand. The spreadsheets often reveal the real process better than the official procedures do.
• Define the target state in measurable terms and select a narrow first scope. A common starting point is one line or one cell with a clear product family and a known problem, such as unplanned downtime on a filling machine or rework on a torque-critical assembly. Document the current values for the indicators you intend to move, so improvement can be shown later. Choose the platform and integration approach only after the scope is stable, since tool selection tends to freeze assumptions early.
• Inventory the equipment and its connectivity honestly. For each machine, record the controller type, available communication interfaces, whether the vendor supports remote data access, warranty conditions that restrict modifications, and who is authorized to change its programs. Some older equipment will need retrofit gateways or manual data capture as an interim step. Budget for network design, cabling, cybersecurity controls, and training, not only for software licenses.

04Recommended workflow

1. 1
   : Map the value stream for the chosen scope. Draw the sequence of operations, the material and information flows between them, and the points where work waits. Mark each point where a decision is made and the information it depends on. This map becomes the basis for deciding which data is needed and where it originates.
2. 2
   : Define the data requirements for each decision. For every decision point, list the variables needed, their source, sampling frequency, units, and acceptable latency. A supervisor deciding whether to reassign operators may need machine state in near real time, while a reliability engineer reviewing bearing wear may need hourly summaries. Avoid collecting a variable that no one will use.
3. 3
   : Establish connectivity and data capture. Connect machines through their native controllers where possible, using standard industrial protocols such as OPC UA or vendor-supported interfaces, and use edge gateways for older equipment. Buffer data locally so that a network interruption does not lose production records. Verify each tag against the physical machine before trusting it.
4. 4
   : Build the information model and context. Link raw signals to work orders, product numbers, lot identifiers, operator log-ins, and recipe or program versions. Raw counts without context cannot tell you whether a stop was a planned changeover or a jam. Keep the model simple enough that a new engineer can read it within a few days.
5. 5
   : Configure the operating functions. Set up the screens, alarms, and workflows that operators and supervisors will use. Define alarm priorities and escalation paths. Limit alarm volume to events that need action, because alarm floods train people to ignore them. Test each function with real shift personnel before go-live.
6. 6
   : Pilot, compare, and adjust. Run the system in parallel with the existing method for a defined period, comparing recorded downtime, cycle times, and quality results against manual records. Discrepancies usually point to missing reason codes, clock synchronization errors, or machines that report status inconsistently. Fix these before expanding scope.
7. 7
   : Expand in controlled stages. Move to the next line or site only after the pilot meets its acceptance criteria and the support model is in place. Assign ownership for each data source, define who responds to alarms outside normal hours, and schedule periodic reviews of configuration and access rights.

05Quality checks, risk controls and compliance

• Verify data integrity continuously rather than once. Build automated checks for missing timestamps, values outside physical limits, sensors stuck at a constant value, and counters that reset unexpectedly. Reconcile system counts with physical counts at regular intervals, such as end of shift for finished goods. Record each correction with a reason, because corrections are themselves evidence about the process and the system.
• Manage cybersecurity as an operational risk. Connected production equipment has often been designed without security in mind. Segment the plant network from business networks, restrict remote access to named accounts with multifactor authentication, keep an inventory of devices, and apply patches only after testing against control applications. The IEC 62443 series is a widely used framework for industrial automation and control system security, and it is a sound basis for policy, though the specific controls you need depend on your risk assessment.
• Machine safety and regulated quality requirements are outside what this manual can settle. Safety functions, guarding, lockout and tagout, and machine-level safety standards are set by local regulations and the relevant standards in force where the equipment operates, and they must be handled by qualified safety engineers following approved procedures. Quality systems in regulated industries, such as medical devices, food, aerospace, and pharmaceuticals, carry their own documentation and validation requirements, and changes to electronic records may require formal validation. Where rules depend on jurisdiction or sector, consult the current authoritative source and your quality or compliance function. This guidance does not replace qualified professional judgment, approved procedures, or any authorization required before changing controls or process records.

06Collaboration and documentation

• Assign clear roles early. A typical team includes a process or manufacturing engineer who owns the outcomes, a controls engineer who owns machine connectivity, an IT or operational technology specialist who owns network and access, a data analyst who owns the information model and reports, a maintenance lead who owns equipment status codes, and a production supervisor who owns operator adoption. Small plants often combine several roles, but each function still needs a named person accountable for it.
• Document the system as it is operated, not as it was designed. Keep current tag lists, network diagrams, interface specifications, alarm philosophies, user access matrices, and change logs in a controlled location. Each change to a control or information configuration should record what changed, why, who approved it, and how it was tested. Documentation that is updated after the fact is useful only if the dates and reviewers are accurate and traceable.
• Use a regular review rhythm with the people who use the data. A short weekly meeting that examines top downtime causes, data gaps, and open alarm issues keeps the system tied to real work. Invite maintenance and operators, not only managers, because they know which codes are misused and which signals are unreliable.

07Measures and continuous improvement

• Choose a small set of indicators tied to the decisions defined earlier. Overall equipment effectiveness is widely used and combines availability, performance, and quality, but it can be misleading if the underlying ideal cycle time or downtime categories are poorly defined. Pair it with first-pass yield, unplanned downtime count and duration, mean time to respond to alarms, schedule adherence, and data completeness rate. Data completeness is an indicator in its own right, since a high OEE figure built on partial data is not trustworthy.
• Set baselines before changes and report trends rather than single values. Compare the same product and line over comparable periods, and note changes in product mix, staffing, or demand that could explain movements in the numbers. Be cautious about attributing gains to the system when other improvement efforts were running at the same time. Where feasible, use a controlled comparison such as a parallel line.
• Improvement should feed back into the data model and the workflow. When a recurring stop turns out to be a sensor fault or a misclassified reason code, correct the model and record the change. When operators consistently ignore a particular alarm, examine whether the threshold is wrong or the response procedure is unclear. Schedule periodic reviews of the whole system, at least annually, to retire signals and screens that no longer serve a decision.

08Common mistakes and how to prevent them

• A common mistake is connecting everything before defining what matters. The result is large data volumes, weak context, and little change in performance. Prevent this by starting from the decision map in the workflow and limiting the first pilot to one line with a specific problem.
• Another frequent error is trusting automated states without checking them. A machine that reports running when it is actually idle, because a light tower output was wired incorrectly, will distort every downstream metric. Verify signal mapping during commissioning, compare system states with direct observation for a sample of hours, and treat unexplained patterns as evidence of a data problem until proven otherwise.
• Teams also underestimate the human side. Operators may enter reasons quickly and inaccurately if the codes are long, if supervisors punish honest reporting of problems, or if the system adds work without giving anything back. Reduce the number of codes to those that drive decisions, make entry fast, and show people how their entries changed a real outcome. Watch for signs of gaming, such as all downtime being coded to the same miscellaneous category.

09Practical checklist

• Confirm the decision or problem the first system scope must solve, and record baseline values for two to four indicators.
• Map the process, information flows, and decision points for the selected line or cell before selecting equipment or platforms.
• Inventory each machine's controller, interfaces, vendor restrictions, and authorized change owners.
• Define the information model, including tag names, units, timestamps, machine identifiers, and standard reason codes.
• Verify each captured signal against the physical machine and reconcile system counts with physical counts at set intervals.
• Confirm network segmentation, remote access controls, and patch procedures with IT and controls staff before connecting.
• Run a parallel pilot with defined acceptance criteria, and document every configuration change with its approval.
• Obtain required safety, quality, and regulatory review from qualified personnel before changing controls or electronic records.
• Review indicators and data completeness with operators, maintenance, and supervisors on a regular schedule.

★Learning sources

• Micro Degree: Smart Manufacturing Systems
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics