Contents · Chapter 1. What DPA is and how to navigate it →
How to read this guide
This guide describes DPA primarily as a working production system: what objects exist in it, what they are for, how they relate to one another, what the user does, and where the resulting outcome can then be seen. Technical details are included where they help explain system behaviour, configure a function correctly, or investigate an abnormal situation.
What determines whether a function is available
DPA is a modular and configurable system, so the set of available capabilities may differ between users and between sites. What a particular user can see and do is affected by permissions, the access scope, assigned production roles, the current role context, enabled services and settings, as well as the connected equipment and the data that equipment can provide. The access scope is the part of the enterprise structure and the associated production data available to a particular account; it does not replace access permissions or production assignments.
Therefore, if a command or section is absent for a particular user, this does not by itself mean that the capability does not exist in DPA. Conversely, the presence of a section in the interface does not guarantee meaningful data unless the required configuration and production context are in place. The following chapters explain such dependencies where they matter to a particular process.
If an expected function is unavailable, check whether the required objects exist and the necessary data is arriving, whether the relevant capability is configured, whether the required service is available, whether the user has the necessary permissions, whether the required object is within the user’s access scope, and whether the conditions for the specific production action are satisfied. The results of these checks help identify why the function is unavailable.
How names and notation are used
In this guide, the names of specific DPA entities and user-facing objects are italicised and begin with a capital letter: for example, Work center, Job, Technology, Downtime, Ticket, Dashboard, or Report. When the same word is used in its ordinary English meaning, no special formatting is required.
After the first mention, CP is used as the customary abbreviation for a control program. The names Operator workplace, Foreman workplace, and Maintenance workplace refer specifically to the specialised DPA workplaces; Operator, Foreman, and Mechanic refer to people’s production roles. The product names DPA Server and DPA Host are retained because they identify specific system components.
Terms such as “real-time data”, “current data”, and “history” describe different time views of production information, not separate independent systems. Likewise, “plan”, “actual”, “machine data”, and “Job result” should not automatically be treated as interchangeable: in DPA they may represent different entities and different sources of facts.
What technical information is included
This guide does not attempt to list internal classes, database tables, or every available programming interface. Those levels are important to developers and integrators, but for most production tasks it is more useful to understand the stable model: which entity holds the required data, which action changes its state, where the result can be seen, and which other parts of DPA it is connected to.
At the same time, technical details are not hidden where they are necessary to use the system correctly. Driver configuration, integration specifics, service boundaries, access permissions, action prerequisites, and diagnostic signs are covered in the relevant chapters to the level required for practical work.
How this guide is organised
This edition proceeds from the overall model and the rules governing access to production data through preparation, planning, and role-based work. It then covers external interfaces, production monitoring and analysis, and responses to production events. If you know DPA only from individual screens, read Chapter 1 in full first: its model of objects and relationships is a useful reference when working with any particular function.
- Chapter 1. What DPA is and how to navigate it. The overall system model: the production cycle, the Work center as a common reference point, the main entities and roles, the connection between equipment and production context, the transition from current data to history, and ways to understand what is happening.
- Chapter 2. Security, users, permissions, and audit. Accounts, groups, permissions, access scope, production roles, function-specific policies, and verification of user actions through audit records.
- Chapter 3. Equipment, work centers, and machine data. The enterprise structure, equipment connection, machine values, states, Indicators, and the role of the Work center as the shared production reference.
- Chapter 4. Production preparation and control programs. Products, Product versions, Technologies, Operations, CPs, CP-to-equipment relationships, Parameter sets, and the engineering context of actual execution.
- Chapter 5. Production planning and execution. From production demand and Work orders to Jobs, equipment and time assignment, actual execution, and production results.
- Chapter 6. Workplaces: Operator, Foreman, and Maintenance. The same production model from the perspectives of the person performing the work, the shift supervisor, and the Mechanic, including actions in each specialised workplace.
- Chapter 7. Connectivity and external interfaces. VNC, OPC UA Server, Kafka, MQTT, and basic use of the public API, including authorisation and short request examples.
- Chapter 8. Monitoring production and analysing what is happening. Monitoring, the Gantt chart, Journals, Dashboards, and Reports: what each view is for and how to move from the current picture to history.
- Chapter 9. Signals. Classic Signals and Signals 2.0: conditions and reaction timing, states, history, handlers, and custom C# scenarios.
- Chapter 10. Production events and handling deviations. Process-parameter control, Tickets, downtime reasons, and automatic classification as sources of events and participants in the response process.
Environment requirements, installation, technical connection of components, first start, updates, backup, and ongoing operation are described in the separate DPA Installation and Operations Guide.
The guide does not have to be read only from beginning to end. When first becoming familiar with DPA, it is useful to follow the chapters in order so that the overall system model remains coherent. For a specific task, you can start with the relevant functional chapter and then follow the relationships to planning, workplaces, external interfaces, monitoring, or response. This is why Chapter 1 gives so much attention to relationships between objects: they are intended to remain a reference regardless of where you begin.