|
|
www.johnstark.com |
|
|
|
Multiple representations of data Different users will want to look at, and work with, different representations of data. Sometimes the representations will make use of the same data type. At other times even the data type will be different. In all cases, the representations must relate to the same underlying data. Modifications have to be made to the underlying data and not to the more superficial representation. At different times, a user will want to work with different structures of data. Different users will want to work with different structures. Different users will want to work with different hierarchical levels within a given structure. Different users will want to include the same part in different functional or hierarchical structures. Engineering, Finance, Purchasing, Production Management, and Assembly may all have different requirements for Bill of Materials structures. The structures and levels have to be consistent. At the lowest levels, the data will be in the form of bits and bytes. These may represent numbers, characters, sounds, and lines. In turn these may represent geometric information, or information about a material or a color. At a higher level, this information may actually represent a part, which in turn may be a component of an assembly such as a wing flap, which in turn belongs to a wing, which in turn belongs to an aircraft. Each level of the structure is of interest to particular users. The machinist drilling the holes for the bolts that attach the wings of an aircraft to the fuselage, wants to know the exact position of the holes and any deviations during drilling, and is not interested in the aerodynamic qualities of the wing. One user may need a bottom-up structure of the product, starting with nuts and bolts and small parts, and then working upwards through larger components and assemblies. Another user may require a top-down structure, starting with the complete product, and then working down through the major assemblies. Some users will be happy to work with 2-dimensional data. An engineer laying out a single Printed Circuit Board may not need to take account of the third (thickness) dimension. On the other hand, a stylist defining the shape of a car wing will require a full three-dimensional representation of data. Other users may need to work with both 2D and 3D representations, and want a modification to one of these to be reflected in the other. A related issue is that of a drawing of a part on paper that is electronically scanned, and then converted from raster format to CAD/CAM vector format. The three representations of the part are different representations of the same object. Each one can play a useful role in the product life cycle. An analyst may need to use the CAD/CAM model. A machinist may need a rasterized picture on a shop floor terminal. A maintenance engineer may have to make a major repair on a customer site, and may need to take a paper drawing to the customer site. Procedures have to be in place so that the different representations can co-exist, and so that any necessary modifications can take place. Any modification made to one of the representations has to be reflected in the others. Under their own data management functionality, different application systems may store the same data in different formats. For example, one system may represent a circle by its center and radius, whereas another system may represent it by three points on its circumference. A third system might represent it by its center and two points on its circumference. Even systems that use the same representation may physically store the data differently. One system may store it in the order x-coordinate of center, y-coordinate of center, radius, whereas another system may store it in the order radius, x-coordinate of center, y-coordinate of center. Multiple versions The engineering environment is typified by many versions and alternatives. Products are made with different models, versions, options, releases and alternatives. Throughout the engineering process, designs change, components are modified, products are restructured and project status is updated accordingly. Management tools such as project management, configuration management and engineering change control are applied to maintain control. The tendency to produce customized products in small batches increases the load on these systems. Whereas thirty years ago a car might have been produced in just a few variants, automotive manufacturers must now handle millions of variants. As product lifetime and time to obsolescence decrease, new models have to be brought out more frequently. The range of products increases and as products are customized, the number of possible combinations of parts rises dramatically. For the manufacturer, the environment becomes increasingly complex and hard to manage. As the number of potential product configurations increases, it becomes harder to keep track of the real configurations of individual products. It becomes harder to make sure that configuration documentation corresponds exactly to individual products. The customer requires the same after-sales service on a product that is effectively a one-off, as if the product had been produced as one of an identical batch of several thousand. The systems that should support versions and changes have not evolved fast enough to handle increased customization and the rapidly increasing number of changes, variants, and versions. The engineering function in many companies is still trying to manage them with manual systems, or with automated systems that are not integrated with the engineering systems, such as the CAD system, on which the changes occur. Manual systems are increasingly failing to control engineering drawings, and to manage engineering changes and product configurations. Typical results are that products are late, and after-sales service is poor and expensive since no one knows what components actually went into a customer's product. Customer-requested changes may be a real problem if they are so expensive that their real cost can not be charged to the customer. Those who create and make use of engineering information are faced with an ever-growing number of versions and alternatives of the information associated with their products. Users are often unsure if they are using the right version of the data. As the rate of change required by market forces increases, the information management systems they use come under pressure with the result that time is lost and mistakes are made. It becomes increasingly difficult to make sure that the information in these systems conforms to the reality of the engineering process. The different versions of systems, such as CAD/CAM systems, are another potential source of problems. The data management capabilities of successive versions of a CAD/CAM system can be incompatible. The system vendor may upgrade the system with the intention of providing better functionality and richer information content, but by doing so may create the situation where an earlier version can not make use of all data created under the new version, and the new version can be limited in its ability to use data created under the earlier version. It may be necessary to 'renovate' existing data when a new version is implemented. A corresponding problem relates to the computer hardware and operating system at the heart of the CAD/CAM system. If past trends continue, hardware currently in use will not be in use in 20 years time, yet some companies will need, in 20 years time, to access data currently being created. It could be difficult for future users to re-create exactly the present environment, unless the company intends to archive its computers, operating systems and programs, as well as its data. When agreement has been reached as to the ownership and location of data, the question will arise of how to manage necessary copies of the data. An engineer working on a new product may want to build up a temporary, individual database containing copies of existing products that are normally stored in a central location under central management. Another engineer, having to make a major change to the design of one of these products, needs to be aware that the design is in use, and to be able to signal to other users that the previous version is unsatisfactory, that changes are necessary, and that these will not be available for several days. A design engineer may be working on a new design. To help reduce lead times, a copy of the design may be sent to a manufacturing engineer before it is officially released. Time can be saved if work on NC programming can start before the design is finalized. However, procedures need to be in place to ensure that further changes to the design (which was not officially released) are transmitted to the part programmer. Mistakes are expensive. The longer it takes to discover that the wrong part has been released to manufacturing, the more costs will be incurred and time wasted, as incorrect documentation is developed, the wrong tooling is developed, and wrong orders are placed with suppliers. In the past, the lead time for many products was dominated by their mechanical component. Recently the percentage of electronic and software components in many such products has increased rapidly. Revision time for these components, in particular for computer programs, can be very short. Unless versions are closely controlled, configuration management becomes a nightmare. |