Data modeling and data management were originally IT-driven activities with the prime goals of providing persistent storage to application systems. Data exchange and interoperability has later become key requirements, extending data modeling to domain models, and data management to hubs and data warehouses. Now, there is a growing demand for adaptable data services coming from business intelligence, networked project design, collaborative design, concurrent engineering, integrated operations and predictable remote maintenance and repair. All these domains have different approaches, and methods for data modeling and management, so the fragmentation and replication of data may still prevail. Providing services for data access, viewing, updating and knowledge sharing among customers, contractors, suppliers, clients and life-cycle service providers is therefore more important to profitability, quality and innovation than ever.

From industry and defense we have learned that a holistic design approach should be adopted to integrate data and knowledge management. In all knowledge work, the life-cycle management of data structures, properties and parameters, values and ranges, dependencies, rules, decisions, and experiences, require in-depth understanding of the data. This in-depth understanding is workspace dependent, local and possessed by practitioners only.

A holistic design approach should therefore be applied, where data models are defined, adapted, and managed by practitioners in a role-oriented Federated Knowledge Architecture. A knowledge architecture is capable of providing the work contexts required for self-serve distributed data management.

Read the rest of this entry »

Advertisement

Computer support to Product Design and Life-Cycle Management is currently dominated by PLM systems, and industry is not very happy with the support provided. Industrial design methodologies and PLM systems create many disjoint, pre-typed product structures. This approach belongs to the era of communicating product knowledge as engineering drawings. In this post, we discuss the need for replacing these static structures by a single federated product model, from which any structure or aspect can be derived.  The federated product model is managed as a family of configurable system and component models, as part of an active knowledge architecture (AKA). With the advent of AKA we see completely new approaches, concepts, operational methodologies, visual modeling methods, enterprise architectures and design solutions emerging. Read the rest of this entry »

Properties define the data values that are important in a domain. In product design, properties and parameters are used for quantifying requirements, for setting agreed upon targets, and for assessing the qualities of different solutions. Product data management (PDM) therefore places properties at the centre of attention, and properties are perhaps the most important kind of elements in PDM standards, cf. independent property definition in STEP, and e.g. the DIN product property dictionary. Design methodology processes are defined according to what kind of properties are defined, related, mapped, balanced, estimated, calculated etc. in each step. Generally, required and target properties are defined long before the objects that will eventually possess them are properly identified or classified.

Yet in IT, properties and attributes are normally treated as second class citizens compared to objects. In database schema, they define the columns of entities, while in object oriented design, they are just subordinate features of object classes. OWL (Web Ontology Language) is a notable exception. It supports property modeling independent of object classes. In the reflective variant OWL Full users may remove the differences between objects and properties, to model features of and relationships between properties. This variant is however seldom applied, because it cannot guarantee sound formal reasoning for automatic execution. In information systems research, Jeffrey Parsons has shown how properties determine classification structures, rather than vice versa. These examples, however, are exceptions to the common practice. This is why our modeling principles include the representation of properties as first class citizens. Read the rest of this entry »

Product Life-cycle Management (PLM) systems have been developed and implemented since the early 1990s. Early solutions were based on a chain of application systems with proprietary user interfaces, information logistics and databases. At the turn of the century product data management standards, protocols and meta-data for application integration matured. Knowledge Based Engineering (KBE), process and collaboration capabilities were introduced. Ten years later customers are still not satisfied with the capabilities offered and value delivered by current solutions. Read the rest of this entry »