|
|
www.johnstark.com |
|
|
|
A multi-application, file-based environment Most of the application programs currently used in engineering activities are file-based. They store data directly in files under the control of the computer's operating system. Another program on a different computer can not easily access the data in these files. There are two reasons for this. The first is due to the operating system and the communications network, and relates to the difficulty of transferring data from a file under one operating system on one computer, to a program on another computer running under another operating system. The second is that information about an object such as a part or product is not independent of the program that created it. The knowledge about the structure and meaning of the data in the file is often only in the application program that wrote the file (or in the head of the person who developed the program), and not available to the other program. As a result, even if the latter program were able to access the data physically, it would not be able to understand it. To overcome the problems of transferring data electronically between programs, it is often transferred manually. Companies often plot a drawing with one system, and digitize it manually into another system. In one aerospace company, it was found that data was being manually transferred like this through a chain of seven functions including assembly drawing, analysis, detail drawing, tool design, NC programming, shop floor instruction preparation, and service manual development. Manual transfer of data introduces errors and wastes time. It can take so long that users may decide it is not worthwhile. Instead, they may work with out-of-date, or incomplete, data. For example, an engineer may not be able to get data directly from the costing system, and will develop a design without taking sufficient account of cost information. Sales staff may not respond to customer queries because it takes them too long to get to information. Sometimes it is possible to develop software that extracts the required information from one program's file and reformats it into a structure that is acceptable to the second program. Initial development of this software, of course, takes time and money. In addition, each time that either of the programs is changed, more effort has to be wasted in maintaining the conversion software. As many program developers are unwilling to inform program users as to the structure and meaning of the data in their files, data in a file often remains understandable only to the program that wrote it. Files 'belong' to the programs that wrote them. For each Island of Automation, an 'Island of Data' appears. Medium-sized companies may have twenty or more Islands of Data. The users of application programs are of course much more interested in real objects such as products and parts, than in the structure and format of data in files. Only too often though, the information on the products is only available after wading through and understanding many sets of files. Again, this represents a waste of time. 'Bridges' need to be built so that information can be moved from one Island to another e.g., part specifications and engineering changes must be transferred from the CAD Island to the ERP Island. Bridges often need to be company-specific, and are time-consuming to build and maintain. Even when the bridges are in place, it will often be found that the information needs additional conversion, interpretation and synchronization. Each new application program has, unfortunately, the potential to become a new 'Island of Automation' and to create a new 'Island of Data'. A company can overcome the problem, in part, by using only an 'integrated set of applications' from a single vendor. In this case some of the physical data transfer problems will be reduced, and the vendor may provide some means for improving the flow of information between the individual programs. In all but the smallest companies, however, it will not be feasible to buy only an 'integrated set of applications' from a single vendor. Since most companies will have needs that can not be met effectively by such a set of applications, other systems will have to be acquired to handle these needs. As a result, new 'Islands of Data' will arise. In the future, as current technologies evolve, and new technologies are introduced, new 'Islands of Automation' will appear. They may be of great importance to individual companies, who will acquire them even if they are not integrated. For the foreseeable future, companies will have to cope with incomplete integration, application-related files and the resulting problems of working with information that is connected in real life but unconnected in the computer systems. These problems, through redundant data, redundant data entry, redundant conversion of data and redundant programs lead to increased operating costs. Even if the engineering function could overcome all these problems and consolidate all its computing and communications activities into one 'Island of Automation', it would still face the problems of working with the 'Island of Automation' in the Manufacturing function, and with the engineering function in partner companies. It is unlikely that these companies would have chosen exactly the same 'Island of Automation' solution. They could have chosen a different solution, or they might have decided to work in an environment that is not integrated. As each application stores the information it requires in its own files, there will be overlap between the information stored by different programs. As an example, many applications will make use of product names and part numbers. Should these change, the corresponding application programs will have to be changed. This takes time and effort, and may introduce errors. As well as storing data in their own specific ways, application programs have their own specific user interfaces. Their approach to common functions, e.g. maths functions, is also specific to each application. Each time someone uses one of these programs they waste effort in first learning, and then remembering, the specifics of the program. Standardization of user interfaces and basic functions is part of the overall approach to the management of engineering data and workflow. File-based application programs are, in part, a reflection of current computer technology, but they are also a reflection of the organizational environment in which they are used. In the past, organizations have tended to be departmental, and application programs matched the functionality and data needs of a particular department. As organizations change and 'departmental walls are broken down', functionality and data needs change. Unfortunately, most application programs can not easily change to meet them. Multiple data definition When there is no standard definition of the data associated with a particular part or product, each user (and application program) can have a different definition of the data, and all the definitions can be different. Different functions may even use different part numbering systems. This leads to errors, and wasted time and money, yet many companies have several different definitions of some data items. A CAD program may have one definition of a part. A part programmer may redefine it. A stress analysis program may use a third definition. In the Bill of Materials, the part may have another definition. It may be redefined for inspection, and again in assembly instructions. Unless the company has introduced strict procedures ensuring that all these definitions are equivalent, there will probably be minor differences between them. These will lead to confusion when modifications are made to the part, or if an attempt is made to reuse the part in another product or design. Since the definitions are not identical, the result of a modification to one definition may not be the same as the result of the same modification to another definition. Special software may have to be developed and maintained to allow users to continue working with their own definition. Often, two users will have conflicting definitions of the same object. As neither wants to appear to have the 'wrong' definition, the data is 'manipulated' so that both definitions can be maintained. This becomes a problem when data has to be transferred from one user, or application, to another. In some cases, part of the definition will be lost. In other cases, something extra has to be added. In all cases, there is the possibility for errors and approximations to be made. This can only decrease the overall quality of the final product. The lack of a standard data definition causes further problems when changes are made by one of the users. The change may mean that the manipulation that was applied previously is no longer suitable. This can set off a chain reaction in other parts of the product life cycle, leading to more mistakes and wasted resources. Similar problems arise with the use and management of data in libraries of standard parts. It has to be decided which data is to be stored in libraries, when it is to be created, who can access it and perhaps most importantly, who can modify it and when. Problems arise with references made in old products to standard data that is to be modified. In some cases it may be best to stay with the old standard. In others, it may be best to bring them into line with the new standard. The level of data definition changes throughout a product's life cycle. In early stages of the product's life, there is little data available. The level of detail increases as the product is developed and used. Once the product has been shipped to the customer, the level of detail required often falls. The definition of the product does not have to be identical at all stages, but it does have to be consistent. Development of a standard definition of a data item needs to take account of the needs of the various users and application programs that make use of it throughout its lifecycle. The choice and implementation of a standard data definition is time-consuming and complex. |