Detail of GB/Z 43339-2023

Introduction of GB/Z 43339-2023

GB/Z 43339-2023 Automation systems and integration - Use case of capability profiles for cooperation between manufacturing software units 1 Scope This document describes an approach for using ISO 16100 to achieve cooperation between software agents by exchanging manufacturing software unit (MSU) capability profiles. The exchanged profiles among agents describe the manufacturing capabilities requested by the requester and to be fulfilled by the performer. 2 Normative references There are no normative references in this document. 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. ISO and IEC maintain terminological databases for use in standardization at the following addresses: ISO Online browsing platform: available at https://www.iso.org/obp IEC Electropedia: available at http://www.electropedia.org/ 3.1 customer requester of the manufacturing activity 3.2 C-subsystem manufacturing software unit requesting the manufacturing activity 3.3 performer provider of the manufacturing activity 3.4 P-subsystem manufacturing software unit providing the manufacturing activity 3.5 capability profile service provider software that implements the capability profile interface [SOURCE: ISO 16100-3:2005, 3.1.2] 3.6 service provider entity that plays the role of capability profile service provider (3.5) and is responsible for preparing and delivering a pair of customer (3.1) and performer (3.3) 4 Abbreviated terms MSU: Manufacturing Software Unit UML: Unified Modelling Language URI: Uniform Resource Identifier 5 Dialogue between C-subsystem and P-subsystem The interaction that occurs between the orderer and the contractor is replaced by the dialogue between a customer and a performer. The dialogue between a customer and a performer can be represented by a sequence of actions associated with the order. The sequence of actions can be represented by the state transition diagram of dialogue. In a production system, the customer is the C-subsystem and the performer is the P-subsystem. Figure 1 shows a dialogue that occurs between a C-subsystem and a P-subsystem. In Figure 1, "C: Request" is the operation of the request to a P-subsystem from a C-subsystem. "P: Promise" is an action promising that the P-subsystem has accepted the request to the C-subsystem. "P: Decline" is an action that the P-subsystem declines with respect to the request to the C-subsystem. Sometimes the P-subsystem offers a proposal. The C-subsystem accepts this proposal. The transition from state 2 to state 2’ shows a sequence of these actions. On the other hand, C-subsystem can offer another proposal for the proposal offered by the P-subsystem. The transition from state 2’ to state 2 shows a sequence of these actions. It is assumed that the dialogue between the orderer and the contractor can be expressed by the state transition diagram of Figure 1, and messages are designed in accordance with this assumption. The following is a description of each state: ——State 1: initial state ——State 2: offer an order ——State 3: accept the order ——State 4: complete the order ——State 5: final state ——State 2': offer a proposal ——State 3', 2'', 3'': final state Annex E gives an example of customization of a state transition diagram of dialogue. Annex F proposes a solution for handling state transitions of dialogues, messages and capacity profile. 6 Procedure until starting the dialogue between C-subsystem and P-subsystem 6.1 Overview C-subsystem acquires the URIs of the P-subsystem that can perform a certain manufacturing activity from the service provider and the P-subsystem requested to perform the activity acquires the URIs of the C-subsystem which requests to perform the activity from the service provider. C-subsystem and P-subsystem start dialogue using the obtained URI respectively. When the C-subsystem sends the first Request message to the P-subsystem, the dialogue shown in Figure 1 starts and exchanges messages according to the procedure in Figure 1. This document assumes centralized control of bids by service providers which are defined in Clause 3. Other bidding processes, such as the distributed bidding process, are future works and are not described in this document. 6.2 Procedure for identifying the dialogue partner using capability profile The procedure for identifying the dialogue partner and establishing the dialogue is as follows. a) C-subsystem and P-subsystem register each capability profile in advance to the service provider. The details of the activities requested by C-subsystem are described in the capability profile of C-subsystem, and the details of the activities that P-subsystem can perform in the capability profile of P-subsystem are described. b) The C-subsystem acquires the capability profile of the P-subsystem satisfying its own request from the service provider, and the P-subsystem acquires the capability profile of the requesting C-subsystem from the service provider. On matching of the capability profile, this procedure conforms to the procedure specified in the ISO 16100 series. c) Before starting the dialogue in Figure 1, there are two cases of message exchanges between C-subsystem and P-subsystem. First case is that the C-subsystem sends a Notify message to the URI of the acquired P-subsystem, and the P-subsystem that received the Notify message immediately sends an Ask Response message to the C-subsystem.

Contents of GB/Z 43339-2023