LIFECYCLE MANAGEMENT | INSTRUMENTATION & CONTROL DESIGN


Left, Figure 2: Engineering hardware design process


the engineering hardware design process can optimise and improve the process to avoid common mistakes in the existing engineering design process. Such mistakes include version confusion caused by management defects, repeated design of similar equipment, stupid mistakes in drawings and so on.


Engineering hardware design process In the engineering design process for digital control systems (DCS), hardware design is the key link between system scheme design and process manufacturing. Establishing lifecycle architecture of the DCS hardware design drawings management system can guarantee the effective implementation of early planning and deployment, and improve the iterative design phase of drawing management. Data management is one of the core elements throughout the design process and through the lifetime, to ensure the control of drawing versions and to effectively improve the quality and efficiency of engineering design. The design process of engineering hardware design


drawing includes: ● Drawings (including schematic drawings, layout drawings, assembly drawings, etc.)


● List preparation (including IO list, network connection list, terminal list, component list, cable list, etc.)


● Checking (including correctness of schematic, rationality of layout, effectiveness of connection, equipment coverage, etc.).


In the compilation process, drawing, list preparation and checking are nested with each other, as shown in Figure 2, these three stages constitute a cyclic iterative process. In each iteration, the drawings are first generated and the detailed list is exported after the generation is completed. The drawing and the detailed list are checked for errors by the checking module after each cycle.


Design of lifecycle architecture The architecture of the lifecycle management system includes a data storage layer, a scheduling interface layer, a business execution layer and a management control layer, as shown in Figure 3. The four layers are connected layer by layer to form a complete data flow and instruction flow. The data storage layer stores and manages the underlying basic data, including component library, preliminary IO list, connection relation set and component set. The scheduling interface layer uses the secondary development interface


of industrial software to manage the basic data uniformly through the scheduling of interface functions. The business execution layer is used to realise auxiliary drawings, automatic inspection and automatic generation. The object of the automatic check function is to produce the layout diagram and schematic diagram. It automatically checks common errors such as unreasonable component layout and violation of wiring design principles, one-by-one. The automatic generation function generates the corresponding signal list and component list from the designed drawings. The management control layer implements the advanced management of the drawings and lists, and realises the control functions at the end of the lifecycle of the drawings and lists, which include archiving, searching, version control, revision management and other functions.


Design of functional modules The system functional framework realises specific functions through different modules. Firstly, low-level code design packages and abstracts the core driver modules into a function library based on a model-driven concept. Then the framework references and configures the function library according to the actual needs to achieve diversified and customised function development. The contents of some functional modules are as follows: U


Manage &


Control


Business execution


Auto-checking Placement


Archiving


Searching


controlling Principle Execute (ActionCallingContext ctx)


Scheduling interface


OnRegister() OnUnregister() OnInitGui() OnInit() OnExit()


Auto-generating Signal list


Version


Revising


Component list OnRegister (ref string Name, ref int Ordinal)


storage


Data


Component library


IO list


Connections


Devices


Above, Figure 3: Function architecture www.neimagazine.com | November 2022 | 37


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45