The use cases in this document generally describe options for accessing different functionalities of a TTD from a client system. The main purpose of scheduling jobs and receive the results are described as well as other practical functions, like accessing or distributing recipes, accessing old TTD result data or checking the machine- or job state.
The use cases defined in this section cover the following topics:
- Identification
- Identification and Nameplate
- Finding all TTDs in a Server
- Configuration
- Available test procedures on the TTD
- Installed / Available tester modules on the TTD
- Available exchangeable parts
- Recipe management
- Transfer of available recipe names.
- Transfer of recipes from TTD to MES.
- Transfer of recipes from MES to TTD.
- Job management
- Schedule a job on the device
- Overview of jobs running and scheduled on the TTD
- Overview over job runtimes.
- Overview over jobs on the TTD and their states
- Result management
- Transfer of test results for tested samples from the TTD
- Transfer of complete test reports from the TTD
- Transfer of complete test results from TTD
- Transfer sample results from non-scheduled jobs
- Transfer job results of non-scheduled jobs
- Device Status
- Retrieving the current state of the TTD
- KPI and Statistics
- KPI calculation
- Events and Notifications, Maintenance
- Upcoming user interactions
- Error messages and warnings
- Calibration / maintenance
There are two use cases in this section. Both are covered by implementing the 3:MachineIdentification.
The user would like to uniquely identify machines, potentially across various OPC UA servers or aggregating OPC UA servers. The user wants to get standardized information about the machine, like manufacturer or serial number, and set user-specific information in order to simplify the usage of the machine.
That leads to the requirements:
- A machine shall be globally uniquely identified.
- Information about the machine, like manufacturer or serial number, can be accessed.
- Application-specific information about a machine can be set by an OPC UA client.
The user would like to easily find all machines managed by an OPC UA server.
This leads to the requirement:
- All machines shall be easy to find in an OPC UA server.
The TTD should be able to provide information about its hard-/software configuration.
A production or quality manager wants to know the available test procedures that can be performed on a TTD in order to schedule upcoming test-jobs. The TTD delivers a list of test procedures. Each test procedure is characterized by the following properties:
- TestProcedureId
- Description
- ProcedureReferences
- IsProcedureLicensed
A production or quality manager wants to know the available exchangeable parts of a TTD in order to schedule upcoming test-jobs or plan maintenance. Exchangeable parts for example are load cells, clamp types, jaw faces and others.
For the identification of an exchangeable part, the following information is provided:
- Name of the exchangeable part
- PartId of the exchangeable part (this can be an Id or a serial number of the part)
- LastCalibrationDate of the device
Additional to the information about the exchangeable part itself the following flags are provided:
- Mounted indicates if the exchangeable part is currently mounted in the device or not.
- Traceable indicates if the part is traceable or not. A part is traceable if it has a part id or serial number.
- MachineReadable indicates if the PartId is machine readable
A production or quality manager would like to know which tester modules are installed in a testing device for the purposes of test planning on a dashboard, control station or mobile device. The tester modules can be hardware modules as well as software-modules. Examples are feeding devices, or yarn-break-detectors.
The following information about a tester module are exposed:
- ModuleName the name of the module.
- ModuleType the type of the module. E.g. hardware or software.
- IsInstalled indicates if the module is installed on the TTD or not.
- Version the version of the soft-/hardware module.
A client (MES) should be able to retrieve a list of the names of all available recipes on the TTD. These names are intended to be used as identifier in the process of job creation on the TTD.
A client (MES) should be able to retrieve a set of recipes from the TTD. Assuming that the (file)size of the content of a recipe is small, it is sent as 0:ByteString to the MES.
A client (MES) should be able to send a set of recipes to the TTD. Assuming that the (file)size of the content of a recipe is small, it is sent as 0:ByteString information to the TTD.
The use cases in this section are covered by using the OPC 40001-3 with the introduction of some additional parameters.
A production manager wants to schedule a job on the TTD.
A production or quality manager wants to have an overview of actual running and planned jobs on a dashboard, control station or mobile device.
A production or quality manager would like to have a statistical overview of the runtimes. E.g. for prognoses of average testing times on a dashboard control station or mobile device.
A production or quality manager wants to have an overview of scheduled jobs and their states on the TTD.
A client (MES) wants to retrieve test results for the tested sample from the TTD. The test result is associated with the SampleId. The testresult itself contains the following statistical data:
- ResultKey Unique Identifier of the measured property defined by the tester application.
- ItemCount Number of valid tests that were calculated in the statistics.
- MeanValue The mean value of the valid tests.
- StandardDeviation The standard deviation of the valid tests.
- CoefficientOfVariation The coefficient of variation value of the valid tests.
- MinValue The minimum value of the valid tests.
- MaxValue The maximum value of the valid tests.
- ConfidenceInterval95 Confidence interval of measurement. 95% confidence interval.
A client (MES) wants to retrieve a complete test report (e.g. pdf file) from the TTD. The test report is associated with the JobId.
The client (MES) requests detailed test data (raw data) of a specific TesterSampleResultId. The Result provided by the TTD contains the URI where the raw data of the test is stored. The main purpose of this use case is to access large amounts of measured raw data generated for a test job not intended to be accessible via the OPC UA interface and not intended to be stored on the MES.
The client (MES) wants to retrieve sample results for jobs that were not scheduled by the client (MES). For a non-scheduled job the TTD generates a unique Id replacing the jobId.
The client (MES) wants to retrieve test results for jobs that were not scheduled by the client (MES).
A production or quality manager would like to have an overview of the TTD state (e.g., running, idle or stopped) that can be shown on a dashboard, control station or mobile device. Additionally, the error states should be visible on the systems.
A production or quality manager wants to have an overview of KPIs like OEE at a MES system or dashboard.
For a maintenance technician or machine operator working on multiple TTDs, it is helpful to have a dashboard showing which of the testers requires the next manual intervention.
A production, quality or maintenance manager would like to have all the relevant, currently active errors and warnings of the TTD visible on a MES system or dashboard.
A production or quality manager wants to know the date of the last and upcoming calibration or maintenance task on the TTD.
A production-, quality- or maintenance manager would like to have all the recent errors and warnings of the testing device visible on an MES System or Dashboard. To achieve this goal the general history mechanism for events as defined in OPC 10000-11, OPC Unified Architecture - Part 11: Historical Access is used.