Introduction to the Business Object Model

The Business Object Model is a model of objects, properties, relationships and operations that represent business entities.

For information on the rationale for the architecture explained using a language analogy, see the Architecture Rationale page.

The Business Object Model is the middle layer of the BDA Architecture, with the Business Concept layer above and the Data Model layer below. Go to the Architecture Introduction for more details on these layers.

Introduction to the most commonly used objects

Study

Study icon

A collaborative Study is package of work that is launched by a Programme to drive the evolution and maturity of something.

A Study can be for many reasons e.g. evolving the design, managing change, performing trade-off analysis, investigating sensitivity of a solution to Uncertainty, performing Optimisation, developing new methods and tools, combining results from other studies into a single baseline.

A Study has:

• Concepts to be investigated.

  • These can be models that are to be investigated, documents that describe the new concepts like Technology Standards, or Material Specifications etc.

• Objectives to be met.

  • These can be a description of what is to be achieved, or references to requirements.

• Inputs to start from.

  • These are existing results from earlier studies that are to be evolved during the course of this Study. Or they can be methodology objects to use as templates (see below).

• Roles of people and organisations.

  • This allows the work in a Study to be assigned or delegated to other people, teams or organisations

• The package of work to be controlled and managed

  • This is an Associative Model Network (see below) the defines the models to be created and their associativity

Study package of work

The relationships are flexible allowing for many alternative Study Management configurations, including nesting studies and management of multiple, interconnected Associative Model Networks.

Associative Model Network [AMN]

AMN icon

An AMN is a container that identifies the elements that together comprise a set of “results” for a Study.

It includes the audit-trail of what is to be done, and what has been done, i.e. the associativity.

Each element in the AMN has an understanding of its dependencies (what it is derived from), and so it makes up a network of associative models. These together allow the record of “who”, “what”, “where”, “when”, “how” and “why”.

The template version of the AMN is a Collaborative Model Template [CMT]; see Methodology Objects below for more details

Associative Model Network vs. Workflow

The work package is represented with an Associative Model network rather than a Workflow because it uses a model based approach with the following advantages:

• The process elements do not have to be specified. Sometimes these are not known (e.g. for new development, or for a process that is informal or not automated), and only the model dependency needs to be recorded.
• The information for a model dependency is “owned” by the model, (i.e. the relationships are from the model to the inputs, not from the inputs to the model). This means the owner of the model is in control of its dependencies.
• There can be a choice of process elements, and these can be switched without disrupting the network view.
• The resultant network is a set of product information with dependency audit trail which can directly be used for archiving

The information surrounding the elements in an AMN implies a process flow, so a workflow could be extracted or visualized from the information.

The information from the managing Study is linked to the Associative Model Network as follows:

• Concepts to be investigated.

  • These are linked to the models and key values, for example it could be a new material specification that is to be investigated for its thermal behaviour in an existing design.

• Objectives to be met.

  • These are linked to models, key values or methods to indicate what is to satisfy the requirement and what the evidence of satisfaction is.

• Inputs to start from.

  • New models can be derived from these inputs, or the inputs could be models that are to be further evolved (i.e. new versions created).

• Roles of people and organisations.

  • There are many different roles that can be assigned depending on the model, e.g. who is to manage, who is to execute, who wants to watch, who is to approve, who is to authorise release, etc.

Associative Model Network content

Model Instance

MI icon

A Model Instance is the object that identifies specific content (numerical data, behavioural data, geometrical data etc) for the product. A model instance has a lifecycle, starting as a entity to plan the work to be done and concluding when the completed models are associated to the model instance using documents.

It can be at any level of granularity, for example:

• a single parameter value level

  • a 1-D line/curve/vector level
  • a 2-D/3-D matrix/surface/diagram/solid
  • a composite set of multi-dimensional data

A Model Instance belongs to an Associative Model Network (AMN). It is derived from other model instances and key value instances (note these do not have to belong to the same AMN). It can also identify the model instance from which it is evolved. This evolution is similar to versioning, but allows an evolution tree to be constructed rather than just an evolution line as is implied by versioning.

Model Instance Evolution Tree

Key Value Instance

A key value instances are significant values that need to be exposed in an Associative Model Network, e.g. for display on dashboards, or for monitoring and control of the network.

Because it is not fixed which models they are extracted from, it allows different studies to compute the same key value with different levels of fidelity, or maturity, For example a component “weight” value can be computed using an approximation model in the concept phase Study, and another instance of the same component weight can be computed in a detail design phase using a complex geometric model.

As with Model Instances, the key values do not have versions, but can specify their evolution.

KVI icon

Methodology Objects (Collaborative Model Template, Model Type, Key Value Type)

Methodology objects can be thought of as templates or definitions. Unlike the instances, they have contextual versioning.

The main objects are:

• Collaborative Model Template

  • This can be thought of as a template for an Associative Model Network. It is the context for associativity between Model Types and Key Value Types. It can have documentation for explaining the intended use of the template.
  • CMTs can be composed of other CMTs. This is useful where templates from several disciplines, teams, or organisations are being combined into a bigger package. The disciplines/teams/organisations can retain control of their own templates, and then these can be consolidated into a combined template.

CMT icon

• Model Type

  • This is the definition for a Model Instance. It has documentation to allow a descriptions, and examples or templates for the instances to combine to form as detailed as needed definition of the model
  • A Model Type can inherit from another Model Type. This allows the reuse of definition information when a specialisation is been created (e.g. Mesh > Thermal Mesh > Wing Thermal Mesh)
  • A Model Type can belong to more than one Collaborative Model Template, and so can have different associativity in the different template contexts.

MT icon

• Key Value Type

  • A Key value Type is the definition of a Key Value Instance. As with Model Types, it can have documentation, can belong to more than one CMT, and so have alternative associativity.

KVT icon

In the diagram below, there are two CMTs that contain the same Model Type that is derived in different ways, and has different Key Value Types extracted from it. I.e. a single Model Type’s associativity is in the context of the different CMTs.

Methodology Objects

The links between all the objects once set up are retained. So when a package of work is set up for a Study, then all the definitions supplied by the Types are available as specifications for what is expected to be delivered.

Study with Associative Model Network and Methodology Objects

Requirements and VV&A

Requirement icon

Requirements are usually managed in official requirements management packages such as DOORs by IBM.

In these packages strict procedures and business processes are embedded according to the needs of the organisation, and regulatory requirements. It is not the intention to replace these systems, but instead to keep the requirements stored in the systems as the source data, and add additional information to these references, information such as models that satisfy them, studies that meet them etc.

However in order to use the requirements in a collaborative environment, sufficient of the source information needs to be available for dissemination. Therefore the requirements have a textual definition, and optional associated documents and properties. Relationships (e.g. Contradiction, Tracing, and Decomposition) between requirements can also be defined

There are two parts to the verification of requirements:

• Identification of the item that the requirement should be satisfied by

Requirement Should-Be-Satisfied-By icon

• identification of the evidence that will show (or has shown) that it has satisfied the requirement

Requirement Verification icon

In the planning phase these can be identified even though the work has not been done. So it is possible to declare up front how a requirement is to be verified, and so this information can be used in planning.

The values of the verification “status” property indicate whether this is yet to be verified, and after verification whether it has passed of failed etc.

Depending on the requirement, different types of object can be used to satisfy it. For example:

• Requirement that all items in the equipment bay must not exceed a surface temperature of x degrees

  • Satisfied by: Components (or their representative model instances) in the equipment bay.
  • Supporting Verification Evidence: Thermal Analysis model instances for all components in the equipment bay

• Requirement that virtual test data is within tolerance of actual test data.

  • Satisfied by: Method.
  • Supporting Verification Evidence: the comparison of the virtual to actual test data. This could be a ModelInstance or a KeyValueInstance of the tolerance which is extracted from the comparison ModelInstance

Illustration of the above Requirement Verification examples

For more details see Requirements and Verification.

Combined view of commonly used objects

The most commonly used objects

How the Business Object Model is structured.

The Business Object Model is structured into logical packages. The first set of packages is needed to carry out “Basic Collaboration”:

• Study Management

  • Studies and the direct relationships to other objects

• Programme Management

  • Networks and instances, used to identify the work to be performed as part of a Study.

    • See also: AssociativeModelNetwork

• Methodology Management

  • Templates and Type definitions for use with the Programme Management

    • See also: Templates and Instances, and Method Definition

• Requirement Management

  • Requirements and their direct relationships to other objects. Includes ShouldBeSatisfiedBy and Verification

    • See also: Requirements and Verification

• Collaborative Process Management

  • The Objects used to manage the work. Requests, Work Orders and Activities

• Document Management

  • Documents and Digital files

• Base Objects

  • The common (mainly abstract) objects that all other objects are built from (inherit)

These are then followed by a series of more specialist packages that are needed for “Risk Sharing Collaboration”:

• Breakdown Management

  • Generic representation of breakdowns (e.g. Product Breakdown, Functional Breakdown). Showing which objects can be included in the breakdown structure. It includes Components and component usage which are described in more detail in Interfaces and Components.

• Interface Management

  • Interfaces, Ports and Connections with the relationships to other objects, particularly links to requirements and representations. Also the use of interface specifications, hierarchies, and constructed and unconstructed interfaces.
  • See also: Interfaces and Components

• Security and Trust Extensions

  • Contracts, Information Rights and Security Classifications, and how they can be applied to the other objects.

• Quality Extensions

  • Approvals
  • Justifications and Assumptions
  • Decisions and Argumentation (see Decision Capture)
  • Distributions
  • Meetings
  • Quality Gate Management (see Quality Gates)
  • Quality Reports
  • Uncertainty Management
  • See also: Quality Domains

• Value Modelling Extensions

  • Extending mainly the Requirements and Study Management package, this adds objects to handle StakeholderExpectations, StakeholderNeeds, and ValueCreationStrategies with the associated QuantifiedObjectives and Targets to fullfil the StakeholderNeeds of the strategy.

• Simulation Extensions

  • This extends the Methodology Management package, adding extra relationships and properties to ModelType and Software

• Geometry Extensions

  • These are extensions to ModelType and ModelInstance to allow the identification or relative coordinate spaces between geometry models. This is particularly important when using representations in the Interface Management package

• Optimisation Extensions

  • This allows the creation of Optimisation template that identifies, which are the variables and constraints and their distribution, which are the objective(s) with their target and resolution, and also which are the constants and additional things to observe during the optimisation.

    • See Also: Correlation

Examples of typical areas of interest showing relevant packages

Collaboration (including Security and Trust)

Collaboration is concerned with the management of the “Team of Trust”. For this the packages of interest are:

• Actors Management: Identification of who is in the team, to which organisation(s) do the belong, what type of person are they, what are their skills.

  • Security and Trust: Identification of the contract the team established under, who is part of the contract, what security rights are associated to the contract, etc
  • Quality Management: Approvals: Who signed the contract

To allow for flexibility, the business rules are not included in the Business Object model.

This means that it can be used for many cases and scenarios, in many different businesses. Examples of business rules would be the type of person who is allowed to approve a contract, or what procedure must be followed to authorise the release of a model that is classified as “Top Secret”.

Workflow set up and management

To allow for greater flexibility, the Business Object Model uses an AssociativeModelNetwork [AMN] to handle the models to be created as part of a Study. A workflow can be interpreted from the information surrounding this AMN.

The packages of interest are:

• Study Management: The problem definition, the Objectives to achieve, the concepts to Study, the point at which to start (this could include links to models in other AMN)
• Programme Management: The model associativity, including the preferred method and the definition of instance data flow into the methods.
• Collaborative Process Management: The Requests, Work Orders and Activities which are all inter-related.

These have roles which are linked to actors.

• Actors Management: The Organisations, Teams and people that can be assigned different roles.
• Methodology Management: The templates (called Collaborative Model Template) that can be used to create AMN. It also includes the detailed definition of Methods (which can include documentation for procedural use of the method), their inputs and outputs for different usages, and including sensitivities and propagation. The Type definitions for Models and Key Values are also part of this package. These can be used as a specification of what (e.g. format, expected analysis etc) is to be delivered.

See also: AssociativeModelNetwork, Method Definition, Methods DataFlow.

Idealisation and meshing

The Business Object Model controls the information surrounding idealised or meshed models. The information contained within the models themselves will be part of the specialist standard for the discipline.

The packages of interest are:

• Methodology Management:

  • The definition of the model. Contained in the documentation linked to the model, and also with the inheritsFrom relationships.

    • Publication definitions within the model definition, these are known as AccessibleModelTypeConstituents
    • It also includes the detailed definition of Methods and Tools (which can include documentation for procedural use of the method), their inputs and outputs for different usages, and including sensitivities and propagation.

  • Interface Management: Interface management is used to divide a problem into achievable pieces, and then to integrate the pieces into a coherent idealised model. The elements in the package can be used to identify the precise points where the interface is positioned, and so allow tools to reassemble the pieces more efficiently.

See also: Method Definition, Methods DataFlow, Interfaces and Components.

Parametric modelling, surrogate modelling and multi-physics and model coupling

This is similar “Idealisation and meshing” above, in that the Business Object Model records the surrounding information, and the specialist standards are used for the discipline data. All the areas of interest that are applicable to “Idealisation and meshing” are also applicable here, but with the additional areas of interest:

• Methodology Management:

  • As “Idealisation and meshing” above plus

    • Properties on the inputs and outputs of methods. This allows constraints and restrictions on the method usage to be declared, and so the various Quality Domains can be declared (e.g. domain of validity) see Quality Domains for more details. Note; the enforcement of any defined constraints of restrictions is the role of the BDA platform to understand and implement.

  • Identification of the Method for which it is a surrogate. E.g. pointing to a complex CFD method that produces a particular output.

Section author: Judith Crockford