# Presentation: 066112

## STEP Architecture: the Next Generation

- Predictions are difficult, especially when they pertain to the future.(Winston Churchill)

**Notes:**
This set of slides is an attempt to predict the evolution of the STEP architecture, in principal based on:
	- the ANSI SPARC architecture,
	- the theory of Object Orientation,
	- contributions to the STEP architecture made before, and
	- personal experience.

## Overview

- Current STEP Problems
- Current STEP Architecture
- Solution Components
- STEP Architecture: 2nd Edition
- Object Orientation for STEP
- Open Issues
- Conclusions

**Notes:**
In particular, this presentation will cover:
Current STEP Problems - the most urgent problems with STEP caused by the current STEP Architecture/Methodology
Solution Components - some basic technologies, on which the next edition of the STEP Architecture/Methodology will be based
STEP Architecture: 2nd Edition - a first and early1 draft of the next edition of the STEP Architecture/Methodology
Object Orientation for STEP - some considerations about the evolution of the STEP architecture into the direction of Object Orientation
Issues - issues not covered by the next edition of the STEP Architecture/ Methodology as outlined above 

## Current STEP Problems

- AP-Interoperability
- Product Centricity
- Information Exchange vs Information Sharing
- Development Process
- Time Consumption
- Resource Requirement
- Dependence on Specific Resources
- Implementation Experience
- Lack of Behaviour (Data and Object)

**Notes:**
The current STEP Architecture/Methodology is based on some assumptions regarding the industrial requirements, that turned out to be wrong later-on. The following problems have been identified as being caused, at least partially, by those wrong assumptions:
AP-Interoperability 
The current STEP Architecture/Methodology does not support the exchange of information beyond the limits of a single AP, at least not to the degree required by industry. Several industry initiatives, especially around PDES Inc. and ProSTEP are working on limited, short-term solutions for this issue. WG10 has been chartered to develop a generic long-term solution.
Product Centricity 
The current STEP Architecture/Methodology requires that all STEP data must be formally connected to a product. This creates problems, when we want to use the STEP Architecture/Methodology outside of the product data domain.
Information Exchange vs Information Sharing 
The current STEP Architecture/Methodology supports the exchange of information - based on exchange files - rather well. At the same time, it prevents the sharing of STEP data by multiple applications in a logically integrated database, because it requires the information models to be overconstrained for this purpose.

## Current STEP Problems

- AP-Interoperability
- Product Centricity
- Information Exchange vs Information Sharing
- Development Process
- Time Consumption
- Resource Requirement
- Dependence on Specific Resources
- Implementation Experience
- Lack of Behaviour (Data and Object)

**Notes:**
Development Process
Time Consumption - the current STEP Architecture/Methodology requires, that 2 information models are developed, one dependent on the other, together with a mapping specification between them. This is considered a waste of time by many AP development projects.
Resource Requirement - the current STEP Architecture/Methodology requires the definition of the information requirements in both formal and textual form. This is considered unnecessarily resource intensive by some AP development projects, especially regarding the structural requirements.
Dependence on Specific Resources - only a very limited number of people is able and authorized to perform some of the functions required by the STEP Methodology. This creates an unnecessary dependence on those resources.
Implementation Experience - the current STEP Architecture/Methodology states, that all implementations shall be based on the AIM, the second information model to be created. This delays implementation feedback unnecessarily.
Lack of Behaviour 
At present, STEP is only standardising data structures. The behaviour, both of the data objects and of the real world objects represented by the data objects, is completely ignored. Both are on the other side requirements for future data exchange and data sharing standards, such as STEP.

## Current STEP Architecture

- Application Semantics

**Notes:**
In the current STEP Data Architecture, we find the following kinds of models:
Integrated Resource Models (IR) - Information models, which describe the information requirements for product data on a structurally highly abstract level.They consist of Generic Resource Models (GIR), which are totally independent of any specific application domain, and Application Resource Models (AIR), which are common for a family of application domains.
Application Reference Models (ARM) - Information models, which describe the information requirements for a particular domain (AP) in structures familiar to the application domain experts.
Application Interpreted Model (AIM) - Information models, which “interpret” the Integrated Resource Models, use the data structures defined in the Integrated Resources to fulfill the information requirements specified by an ARM.
An Application Protocol (AP) is a standard consisting of an AAM, an ARM, and an AIM.
Application Activitiy Models (AAM) - to identify the scope of an AP.These models are not shown on this slide.
The gap between the Integrated Resources and the Application Protocols symbolises the well-known problem of AP-Interoperability. We can see, that this architecture allows APs to share data structures irrespective of whether they underlying semantics are compatible or not.

## Solution Components

- Modelling Scope vs Modelling Context
- The ANSI SPARC Architecture
- Data Exchange and Sharing Architecture

**Notes:**
The first part of this presentation concentrates on the data part of the new STEP architecture. The aspects of behavioural modelling will be handles separately, later on.

## Modelling Scope vs Modelling Context

- The **scope** of an information model is the area of information covered by the model.
- The **context** of an information model is the area of information, with which the model is consistent.
- Extensions of an information model - of its scope - can be made easily, as long as the new scope is fully contained in its original context.
- Therefore the **context of an information model **should always be **as universal as possible.**

- Extension 2

- Orig.
- Scope

**Notes:**
Explanation of the diagram:
The information model is originally defined with the orig. scope within its context.
Extension 1 will not create any problems, as its is totally included in the context of the information model.
Extension 2 on the other side may create lots of trouble, as it goes beyond the original context of the information model.
Note: Traditionally, the scope and the context of an information model are more or less identical. As a consequence, the applications built based on those models are rather monolithic and hard to integrate.

## The ANSI-SPARC Architecture

- The **Conceptual Model **defines the overall scope of a database based on this architecture.
- An **External Model** defines the scope as well as the structural view, that an application or family of applications has on the information defined by the Conceptual Model.
- An **Internal Model **defines the scope as well as the structural view, that a physical database offers to store the information defined by the Conceptual Model.
- The **Mappings **between the models shall be bi-directional instance mappings.

- Conceptual
- Model

- Internal
- Model 1

- Internal
- Model m

- External
- Model n

- External
- Model 1

- ...

- ...

**Notes:**
ANSI-SPARC-Architecture
Other terms for this architecture are 3-Schema Architecture and 3-Layer Architecture.
Conceptual Model
Other terms for Conceptual Model are Logical Schema/Model or Ontological Schema/Model.
A Conceptual Model is best described using semantically irreducible information modelling constructs. This guarantees, that it is extensible over time with no (realistically minimal) impact on existing applications.
There is no requirement, that a Conceptual Model consists syntactically of a single schema.
External Model
Another term for External Model is Application Schema/Model.
There is no requirement, that all External Models together fully cover the scope of the Conceptual Model. Therefore, the set of applications supported by a single Conceptual Model may grow over time.
There is no requirement, that an External Model consists syntactically of a single schema.
Internal Schema
Other terms for Internal Model are Storage Schema/Model or Physical Schema/Model.
There is no requirement, that all Internal Models together fully support the scope of the Conceptual Model. Therefore, the physical databases supporting a single Conceptual Model may grow over time, together with the application requirements.
There is no requirement, that an Internal Model consists syntactically of a single schema.
External and Internal Model
There is no relationship between the number of External Models for a Conceptual Model and Internal Models for the same Conceptual Model. The different characters ”n” and ”m” have been used to indicate this.

## Data Exchange and Sharing Architecture

- The **Conceptual Model **defines the overall scope of a data exchange and sharing environment based on this architecture.
- An **Interface Model** defines the scope as well as the structural view, that an application or family of applications supports to access the information defined by the Conceptual Model.
- The **Mappings **between the models must be bi-directional instance mappings.
- An **Application **is a program or group of programs that accesses and/or stores information defined by the Conceptual Model in a structure defined by an Interface Model.

- Conceptual
- Model

- Interface
- Model 1

- Interface
- Model n

- ...

- Application 1

- Application m

- ...

**Notes:**
Conceptual Model
The term ”Conceptual Model” has here exactly the same meaning as on the previous slide. 
The main difference between these 2 architectures is, that the direction of the flow of control (from External Models through the Conceptual Model to the Internal Models) does no longer exist.
Interface Model
An Interface Model is in principle an External Model and an Internal Model at the same time.
There is no requirement, that all Interface Models together fully cover the scope of the Conceptual Model. Therefore, the set of applications supported by a single Conceptual Model may grow over time.
Application
This term is used here in a very generic way. By intent, a datadase system is an application according to this definition.
Interface Model and Application
There is no relationship between the number of Interface Models for a Conceptual Model and the number of Applications they support. The different characters ”n” and ”m” have been used to indicate this.

## STEP Architecture: 2nd Edition

- Overview Diagram
- Application Data Models (ADM)
- Functional Resources
- STEP-Conceptual Model
- Core Models
- Migration

**Notes:**
We will first see an overview of the new architecture, showing how all components fit together, before we will closer examine the different components.

## Overview Diagram

- STEP
- Conceptual
- Model

- Functional
- Resource

- SCM
- Extensions

- ADM

- STEP ADM

- Application

**Notes:**
This diagram presents the STEP development process in the future.
An ADM (Application Data Model) is developed, potentially based on any number of Functional Resources.
Such an ADM is very similar to the ARM in the current STEP Methodology, especially with respect to its level of abstraction. In contrast to the current STEP Methodology, there is a requirement, that an ADM must be sufficiently complete to support implementation.
Such an ADM may be implemented an put into application use.
If there is a requirement to share information between the scope of this ADM and another one, the ADM will be converted into a STEP ADM by adding the model mapping between the ADM and the STEP Conceptual Model. 
Under ideal circumstances, the STEP ADM will be equivalent to the original ADM, and can be put inot application use as well.
More realistically, there will be areas in the ADM that cannot be mapped to the STEP Conceptual Model. We may decide to leave it this way, accepting that the STEP ADM will not support all applications that the original ADM did.
Alternatively, we may create SCM Extensions (STEP Conceptual Model Extensions) that we will integrate into the STEP Conceptual Model in order to enable the required mapping. This should have no impact on then existing parts of STEP, as long as the SCM Extensions belong to the context of the STEP Conceptual Model.
Integration
Bi-directional Model Mapping
Derivation
Information Flow between
Application and Interface
Model
Line Types:

## Application Data Models (ADM)

- An **ADM **(Application Data Model) is an information model, which defines the information scope of an application domain completely.
- An ADM can be implemented because of its completeness.
- A **STEP-ADM **is an Interface Model for the STEP Conceptual Model, that offers the same capabilities as the original ADM

- STEP
- Conceptual
- Model

- ADM

- STEP
- ADM

- Application

**Notes:**
ADM
Compared with the current STEP Architecture/Methodology, an ADM here is a special case. Here we mean what is currently discussed as Implementable ARM in the STEP community.
From its intent, a better term for ADM would be “Application Information Model”. It has not been chosen, because its abbreviation “AIM” would be ambiguous, as “AIM” in the current STEP Architecture stands for “Aplication Interpreted Model”.
STEP ADM
Compared with the current STEP Architecture/Methodology, a STEP ADM is something totally different from the AIM, as it still preserves the original level of abstraction of the ARM. The closest you can get towards the current AIM in this new architecture is the set of all constructs in the STEP Conceptual Model that is required to map the ADM. 
STEP ADM and STEP Conceptual Model
The mapping between a STEP ADM and the STEP Conceptual Model must be a bi-directional instance mapping.
ADM, STEP ADM, and STEP Conceptual Model
With this separation between the definition of the information scope and its mapping to the STEP Conceptual Model, it will be possible in the future, that a single ADM can be mapped and used in different data exchange standards.

## Functional Resources

- A **Functional Resource **is a pre-fabricated and re-usable model component that supports the development and mapping of ADMs.
- Formally, a **Functional Resource **is an ADM. Its scope might be too narrow to be of any use alone, however.
- A **Functional Resource **can be integrated into any number of ADMs.
- A **Functional Resource **can be associated with multiple Conceptual Models.

- ADM

- Functional
- Resource

- STEP ADM

**Notes:**
Functional Resource
An ADM may be based on any number of functional resources, pre-fabricated and re-usable model components that support the development and mapping of ADMs. 
Formally, a functional resource is an ADM. However its scope may be too limited to be of any use alone.
Functional Resource, ADM, and STEP ADM
In principle, every ADM and STEP ADM can be used as or converted into a Functional Resource. However the maintainability and configuration control requirement for a complex standard such as STEP may add some constraints here.
Functional Resource in the current STEP Architecture/Methodology
The current STEP resources consist of some models that carry sufficient semantics to be used as they stand, such as part 42, and others that are more of the character of templates by intent. The first ones are likely candidates for the conversion into functional resources. The others may - potentially after some completions - become parts of the STEP Conceptual Model. 

## STEP Conceptual Model

- The **STEP Conceptual Model** is the conceptual model for STEP.
- Its **context** should be as universal as possible and achievable.
- Its **scope** is at least product data.
- Its **scope** may grow beyond product data over time, due to requirements coming from industry and other users.
- Extensions may be integrated into the STEP Conceptual Model over time as required.

- STEP
- Conceptual
- Model

- ADM

- STEP
- ADM

- SCM
- Extensions

**Notes:**
STEP Conceptual Model in the current STEP Architecture/Methodology
There are 2 main sources for the development of the STEP Conceptual Schema:
The parts of the STEP Integrated Resources (40 series) that are on the right level of abstraction.
The entity framework as proposed by Shell.
Current work in the area of computerised ontologies may contribute as well.
Conceptual Model Evolution
The main reason, why this presentation prefers the term “model” over the term “schema”, is the intention to evolve the STEP Conceptual Model over time by adding new schemas without impacting the existing ones.
How do core models fit into this architecture?
In this architecture a core model is an STEP ADM (more general an interface schema), that serves as Conceptual Schema for other STEP ADMs. Such a nested structure is not shown in the diagram, but possible in principle.
Some STEP Application Resources (100 series) may fall into this category as well.

## STEP Core Models

- A **STEP Core Model **is an intermediate level of abstraction between a STEP ADM and the STEP Conceptual Model
- The **Mapping** between a STEP Core Model and the STEP Conceptual Model must be a bi-directional instance mapping
- A **STEP ADM** may be mapped (bi-directional instance mapping) to a STEP Core Model instead of the STEP Conceptual Model

- STEP
- Conceptual
- Model

- ADM

- STEP
- ADM

- STEP
- Core Model

**Notes:**
STEP Core Model
STEP Core Models are not shown on the overview diagram.
Seen from the STEP Conseptual Schema, a STEP Core Model looks just like a STEP ADM.
Seen from a STEP ADM, a STEP Core Model looks just like a Conceptual Model.
In principle, a STEP Core Model is a STEP ADM, which is used to integrate and harmonize other (dependent) STEP ADMs.
A STEP Core Model may depend on another STEP Core Model instead of the STEP Conceptual Model. The STEP B&C Core Model may depend of the STEP AEC Core Model which in turn depends of the STEP Conceptual Model.

## Migration (1)

- Options
- Re-mapping of existing ARMs into STEP ADMs
- most consistent with the new architecture
- does not preserve existing data
- may require completion of ARMs
- long-term goal
- Mapping of existing AIMs
- preserves existing data
- partially inconsistent with the new architecture
- does not preserve current level of AP-Interoperability
- Mapping of the existing Integrated Resources
- preserves existing data
- partially inconsistent with the new architecture
- preserves current level of AP-Interoperability
- insufficient, due to lack of semantics in the models

**Notes:**
.
Mapping of existing AIMs
The statement, that this mapping might not preserve the existing level of AP interoperability,
may be surprising. It is based on the assumption, that the existing ARM and mapping table
will be consulted during the development of the mapping. In this case, an element existing in 
2 AIMs may be mapped on different elements in the STEP Conceptual Model, because of 
their semantic differences. 

## Migration (2)

- Proposal
- Start mapping the existing Integrated Resources to become a STEP Core Model in the new architecture
- Then map the current AIMs to this STEP Core Model
- At this point we’ll fully support the current functionality of STEP
- Then complete and re-map the ARMs to the new STEP Conceptual Model
- Now the new STEP Architecture supports the mapping of data where required.

- STEP
- Conceptual
- Model

- STEP1 ARM
- STEP2 ADM

- STEP1
- AIM

- STEP1
- Integrated
- Resources

**Notes:**
Proposal:
This proposal is based on the fact that data stored according to one STEP ADM can be translated into data according to a different STEP ADM through the STEP Conceptual Model. 
Here the first ADM is the existing STEP AIM, which is transformed into a STEP ADM.
The 2nd STEP ADM is the one derived from the existing ARM of our AP.
Of course, the completion and re-mapping of STEP1-ARMs will only be done, where required by potential users and economically feasible.

## Object Orientation for STEP

- The STEP Conceptual Schema will remain a pure information schema.
- Additional behaviour may be added on any ADM or Core Model level, creating a **STEP Application Object Model **(STEP AOM).
- Different STEP AOMs may share the same data instances on the STEP Conceptual Model level.
- An AOM may be developed as independent of STEP as an ADM.

- product

- id

- name

- description

- frame_of_reference

- product_object

- put_id
- get_id
- put_name
- get_name
- put_description
- get_description
- put_frame_or_reference
- get_frame_of_reference

- product_data

- STEP AOM

- STEP Conceptual Model

**Notes:**
An excerpt from the current STEP Part 41 is used here as an example of the future STEP Conceptual Model, despite the fact that ist structure is not sufficiently conceptual.
The example of the STEP AOM shows only the most limited kind of behaviour. This is a consequence of the visualisation technique chosen, rather than a limitation of the methodology.
This proposal violates the encapsulation principle of object orientation in order to enable information sharing. This technique, which does not require the creation of a “supersystem” around 2 systems to be integrated, is sometimes called virtual object orientation.

## Open Issues

- Mapping Language
- based on Information Modelling Language (EXPRESS-X)
- independent of Information Modelling LanguageWHEN?
- Object Models
- Model granularity
- Behaviour of system?
- Behaviour of component!
- Standardization of behaviour?

**Notes:**
There are 2 categories of open issues:
Mapping Language
Nothing has been said here, that requires a consistent modelling technique for all these models. On the other side, an EXPRESS based mapping language (EXPRESS-X) will become available much earlier than a generic one. A sufficiently powerful generic mapping language will not become available before 2010, as its development is still requiring a significant amount of research.
Object Models
The proposal presented in this presentation deals with the description of the behaviour of system components. It does not solve the problem of the description of the behaviour of whole systems. A solution for the latter is available from OMG (Object Management Group) with CORBA (Common Request Broker Architecture) and IDL (Interface Definition Language), on the other hand.
Another issue is the extent to which object behaviour should be standardised. No experience is available to guide such a decision to date.

## Conclusions

- Problems now well-understood
- Solution components long-established and well-known
- Combination of solution components sufficient to solve the data exchange and sharing problem
- The same framework offers solution for the sharing of system components.
- OMG (Object Management Group) is taking care of the sharing of systems with its CORBA (Common Object Request Broker Architecture) and its IDL (Interface Definition Language).

**Notes:**
After more than 12 years of development, we now do understand the current STEP Architecture and Methodology, together with the problems it causes.
In addition, we can see, that such commonly known and well tested concepts as
Conceptual Modelling,
ANSI-SPARC-Architecture, and ist derivate
Data Exchange and Sharing Architecture,
Object Orientation, and
Virtual Object Orientation
can be fit together to create a solution to all known problems of the STEP architecture and methodology. The flexibility of the solution as sketched here also makes us confident, that the further development of STEP will require adaptations of this architecture, rather than a completely new one.