Managing Component Data with PLIB

This part of PLIB has been developed together with IEC61360. Another part of PLIB models component libraries with families of components. A family correlates to a data sheet which describes a set of components. In the Esprit project CIREP, a subtle extension has been added to PLIB to allow the configuration of family descriptions: A CDIL builds a family template which defines the structures of the data sheet which are used for organising the component information (mainly tables). The overall structure of the PLIB standard and the extension of CIREP are depicted in Figure 1.

Based on the EXPRESS Data Manager, the University of Hagen has developed a tool called CIMT (Component Information Management Tool) which allows the capture and editing of component information accord-ing to the PLIB standard. It builds part of the CIREP tool set which allows the supply of component data in standardised form directly into the CAD database of the end user: CIMT is used mainly by manufacturers (AVX, Philips, Siemens in CIREP) and standard maintenance agencies to define classes, DETs, and CDILs. In addition, it allows manufacturers to capture and store their actual component information in compliance with a proper CDIL definition. All this data can be transferred (as a STEP Physical File) to brokers for incorporation into their search databases (Codus). The end users (Aerospatiale, Thomson) download the information from the manu-facturer's or broker's database and incorporate it into their local design databases by means of the CIHS tool (Component information hand-ling system, Spring). The overall data flow of CIREP is illustrated in Figure 2.

CIMT is an interactive tool which provides a multi-window desktop for the client. It allows component manu-facturers to define a component dictionary which contains component classes and data element types according to the IEC61360 standard. Further-more, templates (called CDILs) for the specification of component families may be defined which structure the properties of a class in tables similar to today's component data sheets. Actual component information (i.e. the component library) can be captured according to these templates, and the information can be exported in form of a STEP File (ISO10303 Part 21).

Implementation aspects of CIMT

The requirements for the implementation of CIMT included platform independence and the possibility to access and manipulate component information via inter- and intranets. These requirements have been satisfied by using a Java based solution: Java is platform independent, and by means of the RMI service, Java objects can easily be transferred between server and client. But since only a late C binding for SDAI was available, we also needed to transport the information from the C layer into Java objects. Here we made use of JNI (Java Native Interface). JNI allows to call functions which are implemented in C from the Java layer, and on the other hand it allows to call Java methods from the implementation of these functions in the C layer.

The resulting architecture of CIMT is illustrated in Figure 3. On the database side sits the EXPRESS Data Manager which provides the late C binding to SDAI. Thus, here we operate with functions like "get attribute", "put attribute", etc. On the other side the Java system has been implemented on a much higher level: Here we deal with operations like "get class information", "get family information", etc. The semantic gap between these two ends is filled by the C/C++ layer which takes the high level calls from the Java layer, performs the required SDAI operations and fills the parameters of the Java calls (i.e. the Java objects). As such, the Java layer does not see the details of the SDAI programming, the C layer provides a high level program-ming interface and shields the Java layer from these details.