## Appendix A  
This appendix contains all of the figures referenced in Section 4. To enhance the readability of this section, the mapping descriptions are repeated in this appendix in line with the figure. The process of mapping YANG to OPC UA model design begins with the YANG \"module\" statement, which acts as the highest level of the YANG data model hierarchy. Each YANG module is then correlated to the model design in OPC UA. The <module-name> from YANG is mapped to the file name in the OPC UA model design. namespace and prefix in the module header are mapped to the target namespace and namespace elements in the model design XML file. Additionally, meta-information, like organization, description, contact, and revision, are linked to a custom-defined object in the model design XML file. The module's data definition statements in YANG are mapped to the object type, variable type definitions, and other elements in the model design XML file. Further sections provide comprehensive details regarding each of these mappings. The namespace from the YANG model is mapped to the default XML namespace, the target namespace, and the target XML namespace in the model design XML file. The prefix statement from YANG is mapped to the namespace element prefix and the XMLPrefix attribute. For every import and included statement in YANG, the OPC UA model design XML file shall include a namespace element with Prefix, XMLPrefix, and NameSpace URL. The \"organization\" statement in YANG specifies the name of the organization responsible for this module, while the \"contact\" statement provides contact information for the module, including the name, postal address, telephone number, and email address. Because these statements cannot be directly mapped to any OPC UA model design elements, a custom object type named \"moduleinfo\" is created, as shown in Code A1. An object instance of this type is then mapped with these statement values, as shown in Figure A4. The \"revision\" statement is an essential part of the YANG schema, providing detailed revision information and dates related to the module's editorial history. However, it cannot be directly mapped to any OPC UA model design elements. To address this, a custom object type called \"revisioninfo\" is created, as defined in Code A2, and an object instance of this type is mapped with these statement values. leaf is the simplest data definition in YANG, which is, at most, one instance with data values, and it has no child data definition statements. The leaf statement defines a scalar variable of a particular built-in or derived type. The config statement in the data definition identifies whether the definition represents the element's configuration or the state data. Any data definition defined as a config to true can be edited. Otherwise, it can only be  
Figure 14: Custom object type for module information. observed. If the leaf statement is defined with config as \"false\", then it is mapped to a property node, as shown in Figure A8, and with config as \"true\", it is mapped to a variable node, as shown in Figure A9. leaf-list statement is used to define an array of particular data types. leaf-list contains a list of unique leaves with a key that refers to their value. Like the leaf statement, the leaf-list is mapped to a property node or variable node in OPC UA with the ValueRank attribute of the node set to OneDimension and the ModellingRule attribute set to \"ExposesItsArray\". container is a data definition that wraps one or more child data definition statements. The OPC UA address space model does not provide a node for representing the container; hence, the container is emulated by generating a custom ObjectType, as shown in Figure A11, and defining an object instance to the custom object type. Figure A7: Custom object type for revision information. Figure A8: YANG leaf with configuration as false to OPC UA property node mapping. Figure 10: YANG leaf-list to OPC UA array mapping. Figure 11: YANG container to OPC UA custom object type.