• Keine Ergebnisse gefunden

This chapter discusses some important aspects for further developments in CIM-OSA. lt concentrates on the CIM-OSA executable models, the generic approach to all three types of Front-End Services, and the migration of the proprietary machins control systems into the CIM-OSA system.

CIM-OSA is a lang running research project of the Commision of the European Communities in the CIME area (Computer-lntegrated Manufacturing and Engineering). lt supports the efficient design, manufacture and distribution of high quality products, and provides European enterprises with the flexibility to respond rapidly to market opportunities. CIM-OSA applies the most advanced information technologiss to: process modelling, real-time planning and scheduling, information integration, factory communication, automation, etc. Furthermore, CIM-OSA is an open system architecture which enables component developers, suppliers and end users to join tagether in product development.

However, CIM-OSA is still under development. Even if the main framewerk of the CIM-OSA concepts has been established, there are still details to be improved.

These will be a challenge for research institutions, software houses, industrial CIM-users, etc.

Executable Model of Cl M-OSA

CIM-OSA provides an integrated methodology from the process design to the manufacturing. A set of lntegrated Enterprise Engineering Tools will be used to support an enterprise modeller to manipulate the constructs. The outcome of this task are the Domain Process Models with associated data objects. They are stored tagether in external Data Base Management Systems. The models and the data objects can be directly accessed and executed under the control of the lntegrating lnfrastructure (118). This feature enables a consistent and complete information processing from the process design to the manufacturing, and is known as a CIM-OSA Executable Model.

The test scenario has shown the feature of a CIM-OSA Executable Model but only limited to the Function View ot the modelling task. lt would be interesting to examine the complete 118 behaviour by extending the case study to the Information, Resource

8. Recommendations w.r.t. CIM-OSA

and Organization View, when the whole IIS prototype is available in the future.

However, we have to keep in mind that the CJM-OSA Executable Model can be achieved only if the representation format of the process models and information objects from the Model/ing Framework are clearly defined and standardized, so that the lntegrating lnfrastructure can understand and execute them.

Generjc approach to all three types of Front-End Services

Actually, all three elements of Front-End Services have the same nature in the control of the FO execution, although the functionalities of the respective FO's remain different. The approach to the MF design separates the generic control mechanism from the FO-specific control knowledge. This approach can be adapted to the development of the other two elements of Front-End Services: Application and Human Front-End. ln fact, this was shown in the test scenario where the execution of

However, the support for the integration of the existing proprietary (non-CIM-OSA conformed) CIM-Modules is indeed very important for the manufacturing industries in building a CIM system. From the pragmatic viewpoint, the integration of the proprietary CIM-Modules, e.g. the CAD applications for the product design, should focus more on the information integration than on the business activities integration.

CIM-OSA offers the Application Front-End (AF) for the control of these types of proprietary applications to enable them to access the common data stored in external Data Base Management Systems. This strategy, however, complicates the AF design, because the Application Front-End not only has to achieve the capabilities of the Machine Front-End but also should include a Client-Server relationship with these proprietary applications.

An alternative solution to this problern is to add another component into the lntegrating lnfrastructure. This component should manage several interface adapters, such that each one is responsible for the interfacing between a proprietary CIM-Module and the Information Services. Figure 8.1 depicts a revised CIM-OSA

lntegrating lnfrastructure. lt aims at the integration of both business activities and information. The external CIM-Modules are therefore divided into two types: the CIM-OSA conformed CIM-Modules and the proprietary CIM-Modules. They are integrated into a CIM-OSA system by the Front-End Services and the Interface Adapter, respectively, which allows the co-existence of both types of CIM-Modules.

lt is conceived that such a CIM-OSA system will be more widely applied by allowing the execution of proprietary CIM-Modules without the control of the Business Services.

Business Services

Fig. 8.1 A revised CIM-OSA lntegrating lnfrastructure

Keys are: HFE: Human Functional Entity, AFE: Application Functional Entitiy, PP&C: Production Planning & Control, HF: Human Front-End,

AF: Application Front-End,

MFE: Machine Functional Entity, CAD: Computer Aided Design, F-Services: Front-End Services, MF: Machine Front-End,

DBMS: Data Base Mgmt. System.

Integration of the proprietary machine control systems into CIM-OSA systems CIM-OSA provides enterprises with a Modelling Framework and an lntegrating

lnfrastructure for the software development for the generation and operation of new

8. Recommendations w.r.t. CIM-OSA

(sub)systems. However, the protection of existing investments and therefore the integration of existing applications to a CIM system is an important factor when considering a new investment in a CIM-OSA system.

Generally, there are two methodologies for the integration of existing applications:

the integration by intertacing and the integration by migration. The integration by interfacing has been shown in the form of Interface Adapter in the previous recommendation above.

Migration of an application into a given system, means the change of the application structure in conformance with the structure of the given system in order to achieve an integrated system. Migration of a proprietary (distributed) application into an open system is a difficult task. lt has to deal with the functional procedures and information objects of the proprietary application. There are several migration processes suggested: the analysis of the proprietary application software, the extraction of the distributed functions, the transformation of the distributed functions, and the testing [Hou 91]. The migration of a proprietary application into a CIM-OSA system needs to design a Domain Process Model which contains the procedural functions of the proprietary application.

The approach of the MF design uses the Control Modelsand the Service Units to control the MFO executions. Each Service Unit is used for a specific purpese to co-operate with remote machine controllers. Therefore, a Service Unit, tagether with its co-operating Program Unit of the machine controller, can be viewed as a basic oparational unit for a specified job. ln fact, these basic oparational units provide a good basis not only for the implementation of Function Models, but also for the migration of the distributed functions of proprietary applications.

The integration by interfacing concentrates only on the information exchange of the proprietary parts with the CIM-OSA applications. The proprietary applications remain almost unchanged. By the short-term strategy of an enterprise, this kind of integration can achieve an integrated working system in a short time, but from the long-term aspect it loses the benefits of a CIM-OSA system.