Search

KR-20260067053-A - A method for authentication-based BOD exchange for interoperability

KR20260067053AKR 20260067053 AKR20260067053 AKR 20260067053AKR-20260067053-A

Abstract

To exchange data between application devices having different specifications, a transmitting device converts a transmission message into a standardized BOD, an authentication server authenticates the BOD and issues an authentication key, and a receiving device verifies the received BOD document through the authentication key of the document, the method comprising: (a) a step in which the authentication server stores at least one scenario, wherein the scenario consists of a node representing the application device and a directional edge representing the delivery of the BOD document; (b) a step in which one of the plurality of application devices (hereinafter referred to as the source device) converts its own document into a BOD document; (c) a step in which the source device transmits the converted BOD document to the authentication server and requests the issuance of an authentication key for the BOD document; (d) the authentication server performs a standard conformity check and an interoperability check for the BOD, wherein the standard conformity check examines whether the BOD is written in accordance with standard specifications, and the interoperability check examines the mapping results of the BOD performed by each application device; (e) the authentication server issues an authentication key for the check results and sends the issued authentication key or a BOD document with the issued authentication key attached to the source device; (f) the source device transmits the authentication key and the BOD document, or the BOD document with the authentication key attached, to another of the plurality of application devices (hereinafter referred to as the target device); and (g) the target device receives the authentication key and the BOD document, or the BOD document with the authentication key attached, and verifies the corresponding authentication key and receives it only if verified. Through the system described above, by verifying whether the BOD generated by individual application systems conforms to standard specifications and interoperability with other application systems and issuing an authentication key, the stability and reliability of message exchange can be enhanced by distributing only authenticated BODs.

Inventors

  • 정희태

Assignees

  • 주식회사 아이핌

Dates

Publication Date
20260512
Application Date
20241105

Claims (10)

  1. In an authentication-based BOD exchange method for interoperability performed by a plurality of application devices and an authentication server, (a) A step in which the authentication server stores at least one scenario, wherein the scenario comprises a node representing the application device and a directional edge representing the delivery of a BOD document; (b) a step in which one of the plurality of application devices (hereinafter referred to as the source device) converts its own document into a BOD document; (c) A step in which the source device transmits the converted BOD document to the authentication server to request the issuance of an authentication key for the BOD document; (d) The authentication server performs a standard conformity check and an interoperability check for the BOD, wherein the standard conformity check examines whether the BOD is written in accordance with standard specifications, and the interoperability check examines the mapping results of the BOD performed on each application device; (e) the authentication server issues an authentication key for the inspection result and sends back the issued authentication key or a BOD document with the issued authentication key attached to it to the source device; (f) the source device transmits the authentication key and the BOD document, or the BOD document with the authentication key attached, to another of the plurality of application devices (hereinafter the target device); and, (g) An authentication-based BOD exchange method for interoperability characterized by including the step of receiving the authentication key and the BOD document, or the BOD document with the authentication key attached, and verifying the authentication key and receiving it only if verified.
  2. In paragraph 1, The node in the above scenario has mapping information as attribute information that maps the message of the device to a standard message, BOD, and An authentication-based BOD exchange method for interoperability, characterized in that the directional edge of the above scenario has the structure and data set of the transmitted BOD as attribute information, the data set is composed of items and data formats of items, and the items are nouns or verbs.
  3. In paragraph 1, An authentication-based BOD exchange method for interoperability, characterized in that the above scenario consists of at least two nodes and at least one directional edge, and one operation is performed by executing one scenario.
  4. In paragraph 2, In step (d) above, the authentication server parses the BOD to separate and extract items of words or terms, and verifies each extracted item step by step, wherein in step 1, it determines whether the item is uppercase or lowercase and examines compliance with the rule for uppercase notation; in step 2, it examines whether all letters are uppercase in the case of abbreviations; in step 3, it performs verification regarding uppercase notation for the first letter; in step 4, it verifies whether the English text is composed of the entire word and verifies the specific spelling of the word; in step 5, it performs an authentication check on the noun form of the word; in step 6, it performs verification regarding spacing and prohibits spacing in the case of words or terms; in step 7, it confirms that the use of special characters is prohibited in words or terms; and in step 8, it determines whether homonyms are used. An authentication-based BOD exchange method for interoperability characterized by checking whether words and terms of separated items match the contents of a dictionary by referencing a word dictionary or a term dictionary for each verified item at each stage.
  5. In paragraph 2, In step (d) above, if the item is a verb, the authentication server performs step-by-step verification on the verb, wherein in the first step, it inspects based on naming rule verification and diagnoses whether there are any naming rule anomalies by classifying each verb type; in the second step, it verifies the verb according to the action type of each synchronous and asynchronous verb, the notation of the verb according to the request type, and the content of the dependent response type verb; in the third step, it verifies whether the application of the flow of the verb request/response pair corresponding to the source/destination state information of the verb information defined in the standard specification is valid and verifies the processing of the corresponding verb of the synchronous verb; in the fourth step, it verifies the corresponding process corresponding to the verb processing flow of the asynchronous type; in the fifth and sixth steps, it verifies the action processing for response processing or termination processing according to the corresponding scenario; in the seventh step, it distinguishes special characters for the verb; and in the eighth step, the final verbs verified in steps are stored in the verb table. This characterizes an authentication-based BOD exchange method for interoperability.
  6. In paragraph 4, A certification-based BOD exchange method for interoperability, characterized in that, in step (d) above, the certification server calculates the standard conformity compliance rate based on the passing rate for each item in the inspection results.
  7. In paragraph 2, A method for an authentication-based BOD exchange for interoperability, characterized in that, in step (d) above, the authentication server performs standard conformity checks and interoperability checks for the BOD in all applicable scenarios, and derives verification results for each scenario.
  8. In paragraph 2, In step (d) above, the authentication server performs an interoperability check, wherein the authentication server checks the mapping result between the message of the site and the BOD at each site, and the mapping result checks whether the conversion between the item name of the site and the format and value of the item and the item name and the format and value of the BOD has been properly performed. This is an authentication-based BOD exchange method for interoperability.
  9. In paragraph 8, An authentication-based BOD exchange method for interoperability, characterized in that, in step (d) above, the authentication server performs an interoperability check only on the results processed in the corresponding scenario at the time of the inspection request of the BOD document.
  10. In paragraph 6, A method for exchanging authentication-based BODs for interoperability, characterized in that, in step (g) above, the target device checks the standard conformity rate of the authentication key of the BOD and if the confirmed compliance rate is greater than or equal to a predetermined threshold in the target device, it accepts the BOD and otherwise rejects the BOD.

Description

A method for authentication-based BOD exchange for interoperability The present invention relates to an authentication-based BOD exchange method for interoperability, wherein, in order to exchange data between application devices having different specifications, a transmitting device converts a transmission message into a standardized Business Object Document (BOD), an authentication server authenticates the BOD and issues an authentication key, and a receiving device verifies the received BOD document through the authentication key of the document. Generally, companies have long recognized the importance of data to secure business competitiveness and have been implementing and operating various IT applications in stages. However, they are facing difficulties in data utilization and analysis due to interface construction that failed to consider the introduction of new systems and the absence of a standardized manufacturing data framework. For instance, issues such as missing essential data values, non-compliance with valid formats and agreed-upon values between business functions, duplicate data, data inconsistencies between individual application systems, and the failure to provide data when needed occur frequently. Such inconsistent data can be a major factor in erroneous decision-making and may require significant time, cost, and effort to verify. To this end, data structure standards are required to achieve data integration. While data exchange and system architecture standards have been utilized for years to address these issues, there is significant redundancy in integration standards designed to handle the manufacturing value chain. For example, OAGIS (Open Application Group Integration Schema) and B2MML (Business to Manufacturing Markup Language) define messages that enable the integration of manufacturing application systems with low-level systems, ERP, EAM, and other enterprise systems at various levels of detail; MIMOSA and ISA-95 define structures for modeling enterprises and assets at various levels within a company; and ISO 130303 STEP and ISO 15926 support product information lifecycle modeling. However, applying these international standards to domestic manufacturing sites is difficult due to discrepancies with the attributes, terminology, and meanings used in the field; furthermore, their confusing and complex structures can make them difficult for users to utilize. To solve these problems, a standard BOD schema for integrating individual application systems that process data is presented [Patent Documents 1, 2, 3, 4, 5, 6]. As shown in Figure 1, the prior art is a technology for smooth data exchange between application systems of different specifications. That is, the prior art defines a data schema, which is a common message structure, for data exchange between application systems, namely a Business Object Document (BOD), which is a standard data model. DevEditor is a development collaboration tool that generates BODs tailored to the user's context, and Trans API supports system interfaces to individual application systems (or DevEditor). In particular, Trans API converts schemas into standard documents or BODs through mapping tables. In other words, each individual application system (hereinafter referred to as the sending system) converts its own message (a message for data processing) into a standard message (or BOD) and transmits the converted BOD to another application system (hereinafter referred to as the receiving system). The receiving system then converts the received BOD into a message of its own specifications and processes the data according to the converted message. Additionally, the receiving application system generates the data requested in the message and creates a reply message. The receiving application system then converts the reply message back into a standard BOD and sends the converted BOD (or reply message) back to the sending system. The sending system converts the received standard message (BOD) into a message of its own specifications and processes the data of the corresponding message. To this end, each individual application system composes its messages into a BOD using a DevEditor and Trans API. However, as integrated systems for such data exchange become commonplace, DevEditors and Trans APIs may be provided by multiple vendors. In this case, since multiple vendors or various versions of DevEditors and Trans APIs may be implemented differently, it is necessary to verify whether the BOD is generated in accordance with standard specifications. This problem can be resolved by installing an authentication system (or authentication server) to authenticate BODs and distributing the authenticated BODs. To this end, authentication technology is required to verify whether the BODs generated by each individual application system comply with standard specifications and interoperability with other application systems. FIG. 1 is a block diagram of the schematic configur