Projects that specify, design, construct, and/or maintain a system almost always include objects in their Systems Engineering (SE) model. These objects are parts of the system (e.g., subsystems, components, and elements) that fulfill specific functions. Ultimately, the performance of the system is determined by how well these objects fulfill their respective functions. In the engineering process, system requirements are defined to specify the performance of an object required to fulfill a function. Throughout the various phases, it is common for projects to conduct verifications to ensure that the objects meet the system requirements.
Based on observations at projects, the basic model consists of a type element named Object, which includes type properties to store the name and description.
Typically, the type property Name has a data type of Single line text (to contain a brief title for identifying the object), and the type property Description has the data type Text (to provide a more detailed description of the object).
Categorization
It is common for projects to determine the extent to which objects are part of the project’s scope. Objects within the project’s scope are subject to requirements, functions, verifications, and more. Projects often also identify objects outside the project’s scope (sometimes called “context objects”) as they can interact through interfaces with objects within the project’s scope.
Objects with scope property
One way projects account for the scope of an object is by labeling each object as Internal or External. The main advantage of this approach is flexibility, as you can easily toggle the scope of an existing object at a later time. This model pattern is ideal when internal and external objects share the same properties and relations.
When projects adopt this model pattern, a type property Scope is created in the model for the type element Object. Typically, the type property Scope has a data type List that includes the values Internal and External to denote whether the object is inside or outside the project’s scope.
Objects versus context objects
Another commonly used pattern in projects involves distinguishing between objects and context objects. Objects fall within the project’s scope, while context objects lie outside it. A key advantage of this model is that it allows for different properties and relationships to be assigned to objects compared to context objects.
In this approach, projects create distinct element types for Object and Context object in the model. As shown, each element type has a unique set of properties and relationships. By separating Object and Context object in the model, it becomes possible to control the roles of context objects, ensuring they can only be selected as supporting elements for an interface. In contrast, objects can serve as either leading or supporting elements within an interface. This separation prevents interfaces from being created between pairs of context objects that fall entirely outside the project’s scope.
Hierarchy
Many projects structure objects into a hierarchy, known as a System Breakdown Structure (SBS). Decomposing the system into objects enhances manageability and helps identify interfaces between the objects.
Multiple type elements without recursion
Sometimes, projects model the SBS as a nested chain of different type elements. This modeling pattern is typically used when the number of hierarchical levels is fixed, the levels have specific names, and different properties and relations are required for each level.
In this practical example, used by projects to assess the technical condition of existing objects, a Hierarchical derived type element called Element is created in the model for the Object type element. Another Hierarchical derived type element, called Building part, is then created for the Element type element. As a result, the overviews of Objects, Elements, and Building parts display a tree view that helps users navigate through the three levels of the SBS. For both the Element and Building part type elements, the cardinality is set to Multi. This allows users to create multiple elements as children of an object and numerous building parts as children of an element.
As can be seen, each type element has a different set of type properties. The need for different type properties for each element further supports the use of distinct type elements in the model for the SBS.
Single type element with recursion
Most projects adopt recursive relationships between objects in their model. This pattern is ideal when the number of hierarchical levels is flexible, and the same properties and relationships apply to each object.
Typically, the model includes a relation is part of for the Object type element, which is related to itself. In most cases, the cardinality of this relationship is set to Single. When each object has a maximum of one parent object, the hierarchy is easy for users to understand. By updating the Object type element with the configuration setting to Derived element and the Origin relation to the is part of type relationship, the hierarchical setting is automatically enabled. As a result, the Object type element becomes a hierarchical derived type element, providing users with a tree view of objects in the overview.
Lifecycle
When tracking objects over time, it is common to add a Status property to the model with the data type set to List. Examples of list values include Actual and Rejected. This helps filter out objects that are no longer relevant.
If some objects are expected to become irrelevant to the project over time, it is useful to configure the Status property as a Lifecycle property for the Object type element. Additionally, by enabling the Auto archive setting and selecting relevant archive values (e.g., Rejected), only relevant objects will be displayed in the views by default.
TIP: Be cautious when setting a lifecycle property for the Object type element, especially when combined with a hierarchy. Using Auto archive with a hierarchy can be problematic, as it becomes difficult to interpret child objects of an archived parent object. Therefore, it is advisable to use a lifecycle property only when there is no hierarchy or breakdown structure.
Responsibility
It is common to include responsibility in the model, as multiple individuals, disciplines, or organizations manage an object. This allows users to quickly filter out relevant objects.
Internal responsibility
One way to manage responsibility in a project is to assign disciplines to objects. By navigating to the detail view of a discipline or filtering by discipline in a table, it is easy to see what each discipline is responsible for.
In the model, a type relation called has responsible is often created between the type elements Object and Discipline. In most cases, the cardinality of this relation is set to Single, ensuring that individuals do not feel unaccountable when multiple disciplines are involved. A common property for a discipline is its name. Typically, the type property Name has a data type of Single line text (used to store a short name for recognizing the discipline).
Note that instead of using the type element Discipline, projects often consider using the type element Person as the responsible entity for the Object type element. A key advantage of this approach is that the Person type element can be linked to the current user, enabling personalized filtering in tables. In combination with My to-dos, relevant objects can be displayed on a personalized dashboard.
External responsibility
Another way to manage responsibility is by assigning organizations to objects. For example, when multiple contractors are involved in interfaces, it can be beneficial to designate a specific organization as responsible for an object.
When projects adopt this model, a type relation called has responsible is created between the type elements Object and Organization. In most cases, the cardinality of this relation is set to Single, ensuring that organizations do not feel unaccountable when multiple organizations are involved.
Specification
In most projects, system requirements specify performance in terms of an object that must fulfill a certain function. For example, clients develop object specifications in which the system requirements are listed for each system object. Often, similar system requirements are grouped (e.g., by function, aspect, or interface) for each object in the object specification.
It is common practice to create a type relation called specifies in the model between the type elements System Requirement and Object. Typically, the cardinality of this relation is set to Multi, enabling the reuse of system requirements that are more widely applicable.
Allocation
Ultimately, the object specified by the system requirement fulfills the function described by that requirement. Although it is possible to indirectly determine which object fulfills a function by referencing a system requirement, projects sometimes prefer to directly relate an object to a function. For example, functions may sometimes be derived from the hierarchy of objects. In such cases, a direct relation may be useful for traceability.
Note that caution should be exercised when using a direct relation between an object and a function in the model, as it can lead to redundancy and discrepancies with system requirements that relate similar combinations of objects and functions.
To support this approach, a type relation called fulfills can be created in the model between the type elements Object and Function. Typically, the cardinality of this relation is set to Multi, allowing reuse of solutions (i.e., objects) that fulfill multiple functions.
Standardization
Some projects aim to standardize object definitions using a standardized list of object types. These object types are sometimes part of a library, such as an Object Type Library (OTL). By relating an object (e.g., Golden Gate Bridge) to an object type (e.g., Suspension bridge), a common understanding is created among all involved organizations (e.g., clients, contractors, subcontractors, etc.). Another benefit is that object types enable the adoption of other standardized elements (e.g., requirements, functions, interfaces) that can be optionally related to the object types.
Typically, a type relation called is of type is created in the model between the type elements Object and Object type. The cardinality of this relation is set to single, preventing misinterpretation of the object type in question.