Active Knowledge Modeling

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.

Requirements of Networked Enterprising

Global project networking needs adaptable self-serve services. The evolutionary processes of data definition, collection, aggregation, analysis, distribution, integration, usage, modification, and validation must be modeled by practitioners as work progresses. Practitioners and users must be empowered to control access and use to data created, master data quality, manage validation and reuse, and collect experiences. The capabilities in greatest demand are:

1. Collaborative design and innovation, capturing ideas, developing concepts, engineering systems, and controlling dependencies and uncertainties
2. Knowledge management, sharing, adapting, and reusing requirements, specifications, design concepts, systems, components, views and life-cycle experiences
3. Business process engineering driven by aggregated experiences, history of parameter value evolution, modifications, events and situations
4. Holistic design, enabling rule-driven configuration, modularization and solution generation of products and configurable product platforms
5. On the job training through role-play in context-rich workspaces

Traceability, predictability and iterative development should be supported to take advantage of life-cycle knowledge and competence.

Industrial Data Management

To support life-cycle agility customer delivery and support must be driven by evolving situations, events and operations. Conceptual design, functional system design, procurement, detailed design, concurrent engineering, modular manufacturing and integrated operations must therefore be supported by interlinked data models. Life-cycle support across these application domains, as illustrated in the figure below, must facilitate modifications by any discipline at any stage. As an example a change of weight or centre of gravity on one component may have lifespan and network wide impacts on capabilities, rules and practices. Other examples include modifications during operations, and reporting to improve project monitoring.

Figure 1 - Life-cycle models for evolutionary data processing

In the figure above, the horizontal axis depicts the progress in logical stages, while the vertical axis depicts layers of data and knowledge. The models in this abstracted and simplified view will be different in detail and content for most roles involved. The models are not as distinct as the figure may indicate. At the end of stages the different models, their rules and views, should be consolidated, checked for compliance and data quality, validated, and saved in common project repositories.

Most of these data models will contain a wide variety of user defined data, including:

1. Feasibility studies and business analysis that formulate requirements and constraints
2. Concept sketches to capture ideas and language to communicate conceptual designs
3. Functional models, material and operational specifications agreed among customer and suppliers
4. Product design and performance parameters, parameter structures and value sets
5. Product family platforms, composed of configurable systems and components
6. Variant parameters and rules for configuring deliveries to specific markets and customers
7. Norms and local standards, methodologies, guidelines and ”best-practices”
8. Aggregated properties and key performance indicators for progress and operations monitoring
9. Spatial layouts and structural detailing for concurrent engineering and fabrication
10. Procurement data, orders, specifications, drawings and part catalogues
11. Diagrams and aggregated data for analysis, simulation and experimentation
12. Models of life-cycle operations for preventive maintenance, modifications and repairs

Figure 2 depicts the views (rectangles) of different disciplines (triangles) on a single data entity, in this case a piece of equipment for a processing plant. To support collaborative design and concurrent engineering a knowledge architecture must enable users in different roles and disciplines to compare, balance, and aggregate data, and manage dependencies between tasks, rules, views, and data entities.

Figure 2 - Life-cycle knowledge model discipline views and processes

To support these capabilities the data management principles need serious rethinking. Data modeling and data management must become an integral part of role-oriented knowledge management. User defined data models and their many role-oriented and common views should be federated in a role-oriented knowledge architecture. The evolution of the data models should be managed in evolving workspaces, driven by knowledge models and generated from the knowledge architecture.

State of Practice

The standardization wave has dominated data modeling for the last 25 years. Semantic methods promoted by academia have sought to extend standards with more precise definitions and new capabilities, but with limited success. Semantic constructs are to a large extent outputs from design, can cannot be completely predefined prior to innovation and design. Designers, engineers, architects and planners must thus become more involved in knowledge modeling, in data definition, in managing information flow, and in sharing knowledge and workspace contents.

Currently data integration is concentrated on these application needs:

1. Global standards for product data exchange among companies
2. Interfaces to enable interoperation among proprietary application systems
3. Integration across projects, disciplines, and stages supported by adaptive repositories

An example of the global standards initiative is POSC-Caesar ISO 15926 with iRING tools supporting long term data management and exchange among project partners, and their many different systems.

COMOS is a data hub and repository solution. It is based on a set of interrelated domain models, and enables projects to create and manage discipline and application models and logical model dependencies.

The VIVACE project has developed an approach, framework and operational test-case where an attempt is made to cover the management of models as listed. Their collaboration hub extends the standardized data models with process models, as indicated in the left half of figure 3. These aspects preserve the most critical dependencies as knowledge (metadata views), methods, and data. An implementation of the framework is depicted to the right.

Figure 3 – The VIVACE enterprise data management framework and implemented layers (http://www.vivaceproject.com/content/advanced/reports.php)

This framework gives viable solutions to application systems integration, formal data sharing, information flow, and project data management. However, as with most other approaches, modeling, configuration and integration are detached from users and work execution. Self-serve user services to manage data dependencies, parameter and value evolution, critical value range analysis, dependency rules, and data driven operations would give us a far better basis for quality solutions.

User-Driven Data Modeling

Continuous innovation, holistic design, and knowledge management require a new approach which better supports user driven data definition and process evolution. Data models and derived views are needed by different roles for many different purposes. Figure 4 below shows the range of data models in a typical engineering project, from globally shared standards to individual knowledge. As we go up the layers, we limit scope and generality, and increase role-specific detail, precision, contextual richness, and practical value. We also increase the need for users to access and interact with models, views, and rules.

Figure 4 - Data models required for holistic Design and Life-cycle reuse

A federated knowledge architecture will need to manage all these kinds of data, mediating between the autonomy of local views, and the global consistency of standards. In addition to specific values, local views may contain their own metadata and interpretation of shared data. User-driven data processing should allow non-IT people to design project knowledge architectures, create categories of functional solutions, and associate classes with coherent rules for configuration and modularization of solutions.

In an innovation project concept designers would start at the top creating concept sketches and data, while IT architects are concerned about the bottom layer in order to provide persistent storage. The resulting solutions will handle both local nuances of meaning, conflicting views and rapid evolution, while providing storage and services for role-specific viewing, extension and reuse at later stages and in other projects.

Towards a Federated Knowledge Architecture

A federated knowledge architecture brings together and aligns all kinds of data, not just the well-structured, precisely defined models based on consistent standards. To federate the many categories of models in an innovation network, the models must be dynamically aligned and adapted. Data must be captured in the work context. This is best achieved by building the models into an active knowledge architecture, where the data models determine the customizable workspace logic.

Most of the key concepts and methodologies of active knowledge architectures are outlined in previous posts. There is however one concept that we would like to elaborate on: The types of roles shown in figure 5. Roles are based on responsibility for one or more operations, jobs and methods. By exploring the different types of roles that a person may fill, we see the knowledge architecture from a personal point of view. The personal workspace includes local, shared and standard data brought in from the different contexts where the user has a role.

Figure 5 Types of roles in a federated knowledge architecture

Jobs imply responsibility for performing one or many methods, and one method may be performed by many jobs. Personal workspaces may imply all from one to many jobs, and may contain tasks and views of other workspaces for company, project and community jobs. Companies and their formal organizations manage knowledge- and workspaces, while most projects and teams perform work and create workspaces, and finally communities and discipline groups develop, align and standardize.

The users need services to capture local practices, and manage local and common views on data. Views for task execution should be derived from a user defined model, not hardwired into the application code, so an active model-driven architecture is required.