AP scope | AP module | AP contents | AP index | |
Application module: Function based behaviour | ISO/WD 10303-1453 |
This clause specifies the information requirements for the Function based behaviour application module. The information requirements are specified as the Application Reference Model (ARM) of this application module.
NOTE 1 A graphical representation of the information requirements is given in Annex C.
NOTE 2 The mapping specification is specified in 5.1. It shows how the information requirements are met by using common resources and constructs defined or imported in the MIM schema of this application module.
The following EXPRESS specification begins the Function_based_behaviour_arm schema and identifies the necessary external references.
The Function_based_behaviour_arm module provides for both a definition of a behaviour hierarchy and links to all other modules necessary for the specification of the generic modeling elements necessary to support function based behaviour modeling paradigms.
behaviour is built from Function, I/O (Input/Output), and Function Ordering as shown in Concept Model Figure 3. Any Element may be I/O (Light blue shows an entity comes from Concept Model Figure 1.). A Function is a entity of transformation that changes a set of inputs to a set of outputs. Function Ordering orders the functions such that it is possible to represent sequence, concurrency, branching, and iteration.
There are two major forms of representing behaviour. Function based behaviour, independent of state, emerged in systems engineering in the 1970's. It provides for completed functions to enable succeeding functions, for I/O to trigger functions, and for ordering operators to represent sequence, branching, and iteration. The State based behaviour capability within the SEDRES model represented this with a Petrie net model http://www.ida.liu.se/projects/sedres/index.shtml. The last overview diagram of the SEDRES model reviewed by the ISO team (26 Feb 2001) can be downloaded at http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_behaviour/SEDRES_2_poster.ppt?rev=1.1. Associated definitions of terms used where not provided in text from. The content of ISO PAS 20542 is probably close to what is shown in this diagram. This has not yet been checked by the ISO AP233 Working Draft #1 development team. Refer question relating to the SEDRES diagram to members of SEDRES. UML 2.0 contributors may be using a Petrie Net model. These two models need careful comparison. This is all work to be done.
A model for Function based behaviour is given in Concept Model Figure 4. I/O may trigger functions, starting or terminating functions. I/O that triggers is coupled to the function by binding to a Function Control Port. I/O that does not trigger is bound to a Regular Function Port. I/O arriving while a function is active is stored in a queue unless it is terminating I/O.
Function ordering uses a set of operators: AND to define concurrency, Multi-exit Function or OR to represent alternative paths, a sequence operator, and LOOP, Iterate, and Replicate constructs. LOOP and ITERATE require limits to control their termination. Scripts are used to provide detailed control of function ordering. Probabilities are assigned to Or Out to facilitate execution of the behaviour to produce time lines or Monte Carlo simulation.
Tools that are to exchange behaviour information which include timing need to have associated function activation rules unambiguously defined. The respective tool interpretation engines may execute the models, to produce time lines; or, to perform Monte Carlo calculations. These results will agree only if the tools agree on function activation rules.
The following text has been copied (with permission) from Jim Long's White Paper "Relationships between Common Graphical Representations in System Engineering". This work is harmonized with both the AP233 Concept Model and the EXPRESS model defined within the Function Based behaviour module set. The full/original white paper can be downloaded at: http://www.vitechcorp.com/infocenter/papers/CommonGraphicalRepresentations_2002.pdf
BackgroundOver the past several years, systems engineers have evolved to a few graphical representations to present the functional and data flow characteristics of their system design. The most common of these are the Function Flow Block Diagram (FFBD), Data Flow Diagram (DFD), N2 (N-Squared) Chart, IDEF0 Diagram, Use Case, Sequence Diagram, Enhanced Function Flow Block Diagram, and behaviour Diagram (BD). Most of these graphical representations allow the engineer to decompose the functional and/or data models hierarchically.
It is possible to define a unifying view for all of these graphical presentation. This is capsulated both in AP233 Concept Model and in Jim Long's white paper. The following set of modules provide the associated information model:
The objective of AP233's Function based behaviour capability is to provide a data model that can be used as a neutral format for all of the graphical representations defined herein. This data model is "complete", relative to the function based behaviour representation needs of systems engineering.
TerminologyLet us introduce two terms that we use in describing the conditions that allow/cause a function to begin execution. Considering the control and data environment, a function can begin execution if it is both enabled (by control) and triggered (by data). In the case where there is no data trigger specified, a function begins execution upon being enabled. A function is enabled if the function(s) that precede it in the control flow specification have completed execution (e.g., satisfied their completion criteria). A function is triggered when the required stimulus data item becomes available to the function. We are not concerned here with other execution requirements (such as the availability of necessary resources, except in the case of the Dynamic Timeline Diagrams) that could be represented by either control or data structures as necessary.
NOTE The concepts of execution control and triggering as discussed above are enabled by the EXPRESS entities: Regular_port and Control_port.
Function Flow Block DiagramThe Function Flow Block Diagram (FFBD) was the first to be favored by systems engineers and continues to be widely used today (DSMC 1989, Blanchard and Fabrycky 1990 book "Systems Engineering and Analysis"). Figure 1 shows a sample FFBD. An FFBD shows the functions that a system is to perform and the order in which they are to be enabled (and performed). The order of performance is specified from the set of available control constructs shown in Figure 2. The control enablement of the first function is shown by the reference node(s) which precede it, and the reference node(s) at the end of the function logic indicate what functions are enabled next. The FFBD also shows completion criterion for functions as needed for specification (for example, the exits for the multi-exit function in Figure 1). The FFBD does not contain any information relating to the flow of data between functions, and therefore does not represent any data triggering of functions. The FFBD only presents the control sequencing for the functions.
NOTE It may be desirable to create a list of the different graphical representations identified within the module Function_based_behaviour_arm. The contents required for each could then be precisely defined and each could be versioned separately. In application, users tend to use a single view for a while and then switch to another when a need to change views occurs. One version number for all views seems to be undesirable. #### Issue - Discussion needed.
The Data Flow Diagram (DFD), shown in Figure 3, shows required data flow between the functions of a system (DeMarco 1979). This representation has been widely used by software engineers and serves as the basis of many software engineering methodologies and automated tools. The figure shows that data repositories, external sources, and external sinks can also be represented by DFDs. However, DFDs do not show any control constructs for function sequencing or enablement.
The N-Squared (N2) Chart, shown in Figure 4, was developed to show and specify interfaces between the elements of a system (Long et al. 1968, Lano 1977). Figure 4 is the N2 Chart that corresponds to the Enhanced FFBD in Figure 8. When used to show the interfaces between the functions in a system, the N2 chart is equivalent to a DFD - it contains all the information and differs only in format. The N2 chart is commonly used as a complement to the FFBD to provide the data flow information as inputs and outputs of the system functions.
The N2 Chart is structured by locating the functions on the diagonal, resulting in an N squared matrix for a set of N functions. For a given function, all outputs are located in the row of that function and all inputs are in the column of the function. If the functions are placed on the diagonal in the nominal order of execution, then data items located above the diagonal represent normal flowdown of data. Data items below the diagonal represent data item feedback. External inputs can optionally be shown in the row above the first function on the diagonal, and external outputs can be shown in the right-hand column. If desired, data repositories can be represented by placing them on the diagonal with the functions.
The IDEF0 Diagram (see Figure 5) appears to be a derivative of the DFD with a format like the N2 Chart (Groveston, 1989 and FIPS-183, 1993). The primary content of the IDEF0 Diagram is the specification of data flow between system functions. An IDEF0 diagram is often supported by an IDEF1 or IDEF1x diagram indicating data keys with the objective of preserving referential integrity. The IDEF0 diagram does allow the specification of control as an input to a function but does not have the capability to characterize that control in terms of constructs, as the FFBD, EFFBD, and behaviour Diagrams do. The specification of control with the IDEF0 notation is incomplete and, therefore, not executable. The IDEF0 Diagram also represents the mechanism (usually the component to which the function is allocated) which performs the function. Figure 5 is the IDEF0 Diagram that corresponds to the EFFBD in Figure 8.
The EFFBD displays the control dimension of the functional model in an FFBD format with a data flow overlay to effectively capture data dependencies. Thus, the Enhanced FFBD represents: (1) functions, (2) control flows, and (3) data flows. The logic constructs allow you to indicate the control structure and sequencing relationships of all functions accomplished by the system being analyzed and specified. When displaying the data flow as an overlay on the control flow, the EFFBD graphically distinguishes between triggering and non-triggering data inputs. Triggering data is required before a function can begin execution. Therefore, triggers are actually data items with control implications. In Figure 8, triggers are shown with green backgrounds and with the double-headed arrows. Non-triggering data inputs are shown with gray backgrounds and with single-headed arrows.
The Enhanced FFBD specification of a system is complete enough that it is executable as a discrete event model, providing the capability of dynamic, as well as static, validation. A fundamental rule in the interpretation of an EFFBD specification is that a function must be enabled (by completion of the function(s) preceding it in the control construct) and triggered (if any data input to it is identified as a trigger) before it can execute. This allows the engineer maximum freedom to use either control constructs or data triggers (or a combination of both) to specify execution conditions for individual system functions. By augmenting the EFFBD with function duration estimates/budgets and resource constraints and utilization, trade studies can be done using dynamic simulation outputs. Figure 9 shows the output of such a simulation. This figure shows timelines for a resource (MIPS). It also shows timelines for the integrated system functions, indicating the delays in function execution due to waiting for triggers and resources (MIPS). This dynamic view is also capable of showing the status of the queuing of triggering data.
The behaviour Diagram (BD) (Figure 10) is a graphical representation equivalent to the Enhanced FFBD (Figure 8). The primary difference is in the orientation of the control flow: in the EFFBD, control sequencing is from left to right; in the BD, control sequencing is from top to bottom. While it is not shown on the graphical construct, the BD model allows data inputs to a function to be characterized as either triggering (a control capability) or data update (not a control implementation).
As with the Enhanced FFBD, the behaviour Diagram specification of a system is sufficient to form an executable model allowing dynamic validation via discrete event simulation methods.
From the descriptions of the graphic representations, it is seen that the FFBD characterizes only the functional control model and the DFD characterizes only the functional data model for a system. The Enhanced FFBD and behaviour Diagram capture both these limiting models and the continuum between them. Figure 12 shows where all these graphical representations fit on the behaviour spectrum and, therefore, places them in perspective relative to each other in the sense of specifying control and triggering for functions.
The graphical representations that systems engineers commonly use to describe and specify the functionality and data requirements of a system are very closely related when analyzed in the context of data and functional control capabilities. In particular, the FFBD and DFD are limiting cases of the EFFBD/behaviour Diagram representation. The N2 Chart is equivalent to the DFD: so it is, likewise, a limiting case of the EFFBD/BD on the data modeling end of the spectrum. The IDEF0 is essentially a DFD, except that some control capability (no control constructs) is added. The IDEF0 also allows the explicit representation of functional allocation (i.e., what system component performs each function).
NOTE Permission to reproduce copyrighted material (above) has been obtained: Harold: As long as the work is properly referred, you have my permission to cut and paste material from my paper Common Graphical Representations in Systems Engineering for use in the ISO documentation that you are preparing. Best regards, Jim Long, Vitech Corporation. Date: Mon, 25 Apr 2005.
EXPRESS specification:
*)
SCHEMA Function_based_behaviour_arm;
(*
The following EXPRESS interface statements specify the elements imported from the ARMs of other application modules.
EXPRESS specification:
*)
USE FROM
Behaviour_description_assignment_arm;
--
ISO/WD 10303-1483
USE FROM
Expression_assignment_arm;
--
ISO/WD 10303-1491
USE FROM
External_functional_model_arm;
--
ISO/WD 10303-1478
USE FROM
General_model_parameter_arm;
--
ISO/WD 10303-1472
USE FROM
Required_resource_arm;
--
ISO/TS 10303-1267
USE FROM
Resource_property_assignment_arm;
--
ISO/TS 10303-1273
USE FROM
Textual_expression_representation_arm;
--
ISO/CD-TS 10303-1367
(*
NOTE 1 The schemas referenced above are specified in the following part of ISO 10303:
Behaviour_description_assignment_arm ISO/WD 10303-1483 Expression_assignment_arm ISO/WD 10303-1491 External_functional_model_arm ISO/WD 10303-1478 General_model_parameter_arm ISO/WD 10303-1472 Required_resource_arm ISO/TS 10303-1267 Resource_property_assignment_arm ISO/TS 10303-1273 Textual_expression_representation_arm ISO/CD-TS 10303-1367
NOTE 2 See Annex C, Figures C.1, C.2, C.3, C.4, C.5and C.6 for a graphical representation of this schema.
This subclause specifies the ARM types for this application module. The ARM types and definitions are specified below.
The fbb_activity_method_item type is an extension of the activity_method_item type. It adds the data types Activity_method, Product_version_relationship, Required_resource, Required_resource_assignment, Resource_item and Resource_property to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_activity_method_item =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
activity_method_item
WITH
(Activity_method,
Product_version_relationship,
Required_resource,
Required_resource_assignment,
Resource_item,
Resource_property);
END_TYPE;
(*
The fbb_classification_item type is an extension of the classification_item type. It adds the data types Activity_method, Activity_method_relationship, Applied_activity_method_assignment, Class, Context_dependent_unit, File, Identification_assignment, Independent_property, Independent_property_relationship, Product, Product_category, Product_version, Product_version_relationship, Product_view_definition, Representation, Representation_context, Representation_item, Required_resource, Required_resource_assignment, Required_resource_relationship, Resource_item, Resource_item_assignment, Resource_item_relationship, Resource_property, Resource_property_representation, Uncertainty_with_unit, Unit, Value_with_unit and View_definition_context to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_classification_item =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
classification_item
WITH
(Activity_method,
Activity_method_relationship,
Applied_activity_method_assignment,
Class,
Context_dependent_unit,
File,
Identification_assignment,
Independent_property,
Independent_property_relationship,
Product,
Product_category,
Product_version,
Product_version_relationship,
Product_view_definition,
Representation,
Representation_context,
Representation_item,
Required_resource,
Required_resource_assignment,
Required_resource_relationship,
Resource_item,
Resource_item_assignment,
Resource_item_relationship,
Resource_property,
Resource_property_representation,
Uncertainty_with_unit,
Unit,
Value_with_unit,
View_definition_context);
END_TYPE;
(*
The fbb_condition_item type is an extension of the condition_item type. It adds the data types Activity_method_relationship, Applied_activity_method_assignment, Required_resource, Required_resource_assignment, Required_resource_relationship, Resource_item, Resource_item_assignment, Resource_item_relationship, Resource_property and Task_element_relationship to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_condition_item =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
condition_item
WITH
(Activity_method_relationship,
Applied_activity_method_assignment,
Required_resource,
Required_resource_assignment,
Required_resource_relationship,
Resource_item,
Resource_item_assignment,
Resource_item_relationship,
Resource_property,
Task_element_relationship);
END_TYPE;
(*
The fbb_condition_parameter_item type is an extension of the condition_parameter_item type. It adds the data type parameter_value_select to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_condition_parameter_item =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
condition_parameter_item
WITH
(parameter_value_select);
END_TYPE;
(*
The fbb_expression_assignment_item type is an extension of the expression_assignment_item type. It adds the data type Condition to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_expression_assignment_item =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
expression_assignment_item
WITH
(Condition);
END_TYPE;
(*
The fbb_identification_item type is an extension of the identification_item type. It adds the data types Applied_activity_method_assignment, Condition, Independent_property, Product, Product_version, Product_view_definition, Required_resource, Resource_item and Task_step to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_identification_item =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
identification_item
WITH
(Applied_activity_method_assignment,
Condition,
Independent_property,
Product,
Product_version,
Product_view_definition,
Required_resource,
Resource_item,
Task_step);
END_TYPE;
(*
The fbb_required_resource_item type is an extension of the required_resource_item type. It adds the data type Task_step to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_required_resource_item =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
required_resource_item
WITH
(Task_step);
END_TYPE;
(*
The fbb_resource_assignment_item type is an extension of the resource_assignment_item type. It adds the data types Product, Product_version and Product_view_definition to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_resource_assignment_item =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
resource_assignment_item
WITH
(Product,
Product_version,
Product_view_definition);
END_TYPE;
(*
The fbb_resource_item_select type is an extension of the resource_item_select type. It adds the data types Product, Product_version and Product_view_definition to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_resource_item_select =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
resource_item_select
WITH
(Product,
Product_version,
Product_view_definition);
END_TYPE;
(*
The fbb_task_item type is an extension of the task_item type. It adds the data types Product, Product_version and Product_view_definition to the list of alternate data types.
NOTE The list of entity data types may be extended in application modules that use the constructs of this module.
EXPRESS specification:
*)
TYPE
fbb_task_item =
EXTENSIBLE
GENERIC_ENTITY
SELECT
BASED_ON
task_item
WITH
(Product,
Product_version,
Product_view_definition);
END_TYPE;
(*
The functional_behaviour_model type is an extension of the behaviour_model type. It adds the data type Functional_model to the list of alternate data types.
EXPRESS specification:
*)
TYPE
functional_behaviour_model =
SELECT
BASED_ON
behaviour_model
WITH
(Functional_model);
END_TYPE;
(*
*)
END_SCHEMA; -- Function_based_behaviour_arm
(*
© ISO — All rights reserved