Category ' Articles '

12th October 202312th October 2023

Controlling PDUIDs in Import and Export

This is the fourth and last in a short series of posts that explain Project Database Unique IDs (PDUIDs). This post explains how PDUIDs can be controlled when importing information into Cradle.

Exchanging Information

The primary method of moving data into or out of Cradle databases is import/export. Regardless of the form of the data files used, there are some basic characteristics of import operations that affect the handling of PDUIDs and which can be controlled by the user when importing. These choices can be saved with other import options in an import format file. Such formats can be used for later imports, and specified for command-line based imports using the c_io utility. Using import format files is recommended as it ensures consistency between imports.

Default Behaviour

When importing information:

Every item imported will have a PDUID when it is saved, even if the import data does not contain a PDUID
The DID in the PDUID of all imported items will be set to the DID of the current Cradle system. For data that is being loaded from other Cradle systems, this means that the PDUIDs of the items in the original and imported databases will always be different. Even if their PUIDs are the same, their DIDs will be different.
If an item being imported does not exist in the PDUID lookup table, then a new entry will be created in the table for the item. This new entry will have a PDUID. This PDUID will either be newly generated (the default), or if the import data contains a PDUID and the user has chosen to force the import of PDUIDs, then the PDUID from the import data will be used.
If an item being imported exists in the PDUID lookup table and its table entry is marked deleted, then this table entry will be reinstated. If the user has specified to use the PDUID from the import file, the PDUID in the table entry will be replaced with the PDUID from the import file, else the table entry will be reinstated and the imported item will have the original PDUID from the lookup table.
If an item being imported has a PDUID that is already used for a different item in the database, then the PDUID in the import file will not be used and the imported item’s PDUID will be replaced, regardless of any import options to the contrary
All instances of an item have the same PDUID. Therefore, the PDUID of an item in the database will only be changed if all instances of the item can be changed. If there is any reason why all instances of an item cannot have their PDUIDs changed, then none of the instances will have their PDUIDs changed. As an example, if a user tries to import items with Overwrite set On and wants the PDUIDs in the import file to be used in the database, then the user must have RW access to all instances of the item in the database and the import data must update all of these instances.

Force Use of Existing PDUIDs

When importing data, you can choose to ignore any PDUIDs in the import/export file and instead keep the PDUIDs already in the database. To do this, de-select the checkbox Import PDUIDs from file (do not generate them)

This means that:

If an item in the import data does not contain a PDUID, a PDUID will be generated for it as it is imported
If an item in the import data does not exist in the database, then PDUIDs will be generated for them
If the item in the import data does exist in the database, then the items will still have their original PDUIDs after the import and any PDUIDs in the import data will be ignored

Force Use of Import File PDUIDs

When importing data, you can choose to use PDUIDs in the import/export file and replace the PDUIDs already in the database. To do this, select the checkbox Import PDUIDs from file (do not generate them)

This means that:

If the item in the import data does not contain PDUIDs, then PDUIDs will be generated for items as they are imported
If the item in the import data does not exist in the database, then the PDUID in the import data will be used provided that it does not already exist in the PDUID lookup table and if it does exist in the table then if that table entry is active then a PDUID will be generated and if the table entry is not active then the PDUID in the import data will be used and the table entry will be replaced
If the item in the import data does exist in the database, then:
- If the PDUID in the import data does not already exist in the PDUID lookup table then:
  - The PDUID in the import data will be used
- Else if the lookup table entry is active then:
  - If the lookup table entry is for a different item then:
    - A PDUID will be generated and the PDUID in the import data will not be used
  - Else if the user has RW access to all instances of the item and all instances of the item are to be updated by the import then:
    - The PDUID in the import data will be used
  - Else
    - The PDUID already in the lookup table entry and the database items will not be changed
- Else the lookup table entry is inactive so:
  - The PDUID in the import data will be used

Force PID Change

Whenever an item in an import file is to be imported as a new item in a database (not overwriting an existing item) then the PDUID for that new item will either come from the import data (if it contains PDUIDs) or a new PDUID will be generated. The PID in such PDUIDs will be either PID of the current database, or you can force a specific PID.

This can be useful if, you want to distinguish the data being imported with a specific PID, but the import data does not have that PID. For example, if you are importing into a single database data from multiple other databases then you might want to force the PIDs in the PDUIDs of items imported from database “A” to have one value and for the PIDs in the PDUIDs of items imported from database “B” to have a different value.

If you did this then, for instance, the PDUID facilities in queries could be used to distinguish between these sets of imported data.

6th October 202313th June 2023

Cradle Modules – SWE

Cradle-SWE Module

The Cradle SWE module provides reverse engineering and code generation to maintain consistency between a detailed system design and its software implementation.

Software Engineering

There are many contexts for software engineering, each using its own methods and languages. This module is intended for groups using functional methods to build software in C, Ada or Pascal.

Detailed software designs are represented using Structure Charts (STCs) with 3SL extensions to support:

Hierarchical descriptions of software into systems
Programs
Subsystems
Modules and source files
Representation of functions
Representation of basic data types

Software designs are described with diagrams, data definitions and module specifications that hold the pseudo code, descriptions or source code. This software design is cross referenced to architecture, design/analysis models, to requirements/test cases, and to all other data.

The initial design can be code generated to:

C, Ada and Pascal type definition header files (built from the model’s data definitions)
Source files that contain the call hierarchy from the STCs
Call arguments and local variable declarations
Content of the STC’s module specifications’ pseudo code or detailed design material.

Once algorithmic content is added to the generated code, the resulting completed source files can be reverse engineered back into the Cradle database, to update its design diagrams, and both the data definitions and module specifications of these diagrams’ symbols.

Reverse Engineering

Reverse engineering merges the actual source code into the design definitions and specifications. Each source file is subdivided into the individual routines. The component parts are then stored into separate frames in the module specification and data definition items in the database. Every line in each source file is stored in a frame of one of these items in the database.

The Code Generator can be run on the results of the reverse engineering to reconstruct the source files, either as they were, or including any changes made in the design model. In this case, the source code is generated using call interfaces built from the (possibly modified) STCs and the routines’ bodies are created from either the STC call hierarchy or the source code from the previous reverse engineer operation.

The process can start by reverse engineering legacy source code into an initial design model, recovering designs in situations where only the implementation currently exists.

As reverse engineering loads all source files into the database, the source files could be deleted, and instead configuration managed through the Cradle Configuration Management System as part of the design.

The diagrams, specifications and data definitions can contain any number of attributes, including URLs to reference the source code in a source code control system, such as Git or Subversion.

Format of Generated Code

The format of all generated code can be tailored to match your coding standards. Data definitions can be marked to be standard data types and generated into the source code. Header files can be produced from the composition specifications inside the data definitions to create record and variant structure declarations.

Support

The reverse engineering tool supports any compiler programs and conditional compilation directives. It can distinguish application code, application libraries and standard library or operating system / runtime routines, and render the design diagrams accordingly. This uses any combination of regular expressions, and Cradle-supplied or user-defined library routine lists.

Reverse engineering can process one or more source files in one run, creating a hierarchy of design diagrams to represent the code structure beyond individual source files.

Full Traceability

Using the reverse engineering tool creates full traceability across the entire system lifecycle, from user needs to system requirements to analysis, architecture and design models, to test procedures, specifications and test cases, to the source code. Cradle’s transitive cross reference view facilities allow users to directly see the user requirements and acceptance criteria associated with each source code module, and vice versa.

Feature Summary

Please contact 3SL for further information about adding a Cradle SWE module to your existing system.

29th September 202313th June 2023

Cradle Modules – WEBP

Cradle-WEBP Module

The Cradle WEBP module publishes sections of Cradle databases as fully hyperlinked, standalone, websites that can be viewed independently of Cradle.

In general, users will access a Cradle database through a Cradle web UI or a non-web UI such as WorkBench.

There are situations where direct access is not possible, particularly if the users are remote from the database and do not have any external electronic access, of if the data is classified and cannot be sent across a public network, such as the Internet, even if the connections are secured.

In such cases, database information is normally published into one or more documents that are provided to the external users. This works well, except that documents are linear, a sequence of pages, and it is not always easy to explore their contents. This is particularly true for analysis and design models where there are many connections between the models’ components, and also when following cross references between items.

Website Pages

The Web Publisher tool generates a static website containing some or all of the items in a database. This website contains three types of page:

A top-level page
Pages containing lists of each item type that has been published
Individual pages for each item

The pages for individual items contains lists of links to related items of each type, grouped by the type of cross reference.

Diagrams are published as SVG so they can be zoomed, panned and scrolled. All diagram symbols are hyperlinked to lower-level diagrams and to the symbols’ descriptions in specifications and data definitions.

Website Links

So the pages for individual items are connected by hyperlinks in the same way that the database items are connected by cross references.

Users can follow these hyperlinks to explore the information in any way that is convenient to them.

Website Distribution

By being static, the website is fully independent of Cradle. By being read-only, the websites can be distributed on CD or DVD, In effect, the website is a self-contained snapshot of the parts of the database that you have chosen to publish.

Templates/Themes

User-defined criteria specify the item types, and items of these types, to be published from the database. The form and content of the website’s main page can be controlled with a user-defined template. The tables for each item type have user-defined columns and contain any attributes. The pages for items have individual user-defined templates so that the layout and attributes to be published can be controlled.

Collectively these templates are called a theme. Several themes are provided with Web Publisher. You can create your own themes to include your company or project logos and branding.

Items in a Cradle database can contain any number of attributes of a wide variety of types, including URLs. So any item in Cradle can contain URLs that link it to other resources, either on the Internet, or intranet, or data in another environment.

You can include these URL attributes in your templates for the Web Publisher. By doing so, the pages published by the Web Publisher will contain these URLs so that a user browsing the published website can follow the URLs to access the related information, wherever it may be.

Publishing

Websites are published into a user-defined top-level file and a directory containing all other pages. It is easy to link the generated site into a larger set of information, including any site-specific modifications to the hyperlink URLs.

Different baselines, or work-in-progress, can be published to separate websites, for comparison between approved and current activities.

Feature Summary

Please contact 3SL for further information about adding a Cradle WEBP module to your existing system.

22nd September 202313th June 2023

Cradle Modules – WEBA

Cradle WEBA Module

The Cradle WEBA module provides the means to create custom web UIs that allow users to access Cradle databases from web browsers in a manner that is appropriate to their needs and use cases.

Cradle provides WorkBench as the means to access databases and provides many choices to create a customised environment, including start pages and the phase hierarchy. However, WorkBench is not suitable for all users:

Users may not want to install Cradle
Users may be remote from the Cradle system and WorkBench may not provide acceptable performance (despite server-side processing)
Users may not allow Cradle to communicate through their firewall
WorkBench provides more functionality than needed and, therefore, appears too complex

Why use Web UIs?

So there are at least three reasons why a project may wish to create web UIs:

IT restrictions in the use of WorkBench
Performance needs of remote users
Provide simple UIs tailored to the needs of specific user groups

Cradle allows web UIs to create, manipulate or view database information. Each web UI is created to meet the needs of a group of users, either to offer a wide range of UI controls to provide a flexible and powerful UI so users can perform many tasks, or a simple UI that allows users to perform perhaps one or two tasks very quickly and easily.

All web UIs are zero thickness, with no client-side code. There are no browser add-ins or plug-ins needed.

Creating Web UIs

Any number of web UIs can be created. Each is associated with a project-specific user type. Each Cradle login account is also associated with a user type. When a user connects to the Cradle Web Server (CWS) and logs in, the CWS serves the web UI defined for the user’s user type, or a default web UI.

Therefore, the CWS can serve many, potentially very different, web UIs to its users, based on their user types.

Users login to a web UI with the same username and password used with non-web tools. Web-based users have the same access rights to items and Cradle operations as users of non-web tools such as WorkBench and utilities.

Web UIs are created from templates and building blocks provided in the Cradle WEBA module. The module also includes two example web UIs:

A web UI using all blocks to offer a powerful and flexible environment for engineers
A basic UI providing controls over page layout, item creation, viewing and reporting

Using the Cradle WEBA Module

In the example web UIs, users can create, view, edit and delete items and they can manipulate and follow cross references:

Users can navigate through the database using the phase hierarchy, the master tree, or using a table-based browse mechanism,

Items edited in web UIs are locked in the same way as non-web UIs and the API, to prevent simultaneous update by other web or non-web users.

Tables of items shown in web UIs will load into Word and Excel as hyperlinked documents.

Web users can create and use the same queries as non-web UI users. All query processing is server-side in the CWS to optimise the performance for each user.

Views created in WorkBench can be used in web UIs. Items can be edited in table views. Items can be shown in user-defined forms. Binary data can be modified and uploaded in a web UI. Rich text can be shown in web UIs.

Diagrams are shown in SVG. Diagrams can be zoomed and panned. Hyperlinks in each diagram symbol allow users to navigate to child diagrams and from symbols to their descriptions in data definitions and specifications.

Change histories are also fully supported, together with all collaboration facilities, including discussions and alerts.

Authentication to web UIs can use LDAP and support single sign-on. Access to web UIs can be limited to specific proxy servers, network interfaces and remote hosts.

Cradle provides cradle:// protocol URLs that allow direct access to items and query results by external tools.

Feature Summary

Please contact 3SL for further information about adding a Cradle WEBA module to your existing system.

15th September 202313th June 2023

Cradle Modules – PERF

Cradle-PERF Module

The Cradle PERF module applies user-defined calculations to an architecture model, to compare the performance of alternative architectures and apportion performance budgets to subsystem, component and equipment designs.

Simulation is an activity to reproduce a system’s behaviour in an artificial environment to test the system in a variety of scenarios. Simulation is used where testing the real system is either dangerous, impracticable or too time-consuming or expensive. The most fundamental behavioural characteristics of systems are set early in the design process, as alternative architecture topologies are assessed and performance budgets are set. But as there is no behaviour allocated to the components, it is not possible to build a simulation.

Performance Assessment

Performance assessment solves this problem. It is used before behaviour is known and allocated and so before simulation can be used. It can be used:

To confirm if a proposed architecture is viable
To compare performance characteristics of candidate architectures
To define budgets for lower design levels (apportionment)
To aggregate actual values

Performance assessment is expressed in user defined characteristics, typically concerned with timing, data error or precision, such as:

Bandwidth
Utilisation
Size
Cost
Data rate
Staleness
Weight
Power

They can be subdivided, for example to study best case, worst case and typical conditions. They are held as user-defined formulae in the specifications and data definitions of the symbols in the architecture models’ diagrams.

Performance Characteristics

Any number of performance characteristics can be defined and associated with each diagram symbol. Each has its own formula. These are defined using a function library and user-defined calculation routines. This library contains logical, arithmetic, logarithmic, exponential, ladder, table lookup and interpolation routines, amongst others.

System performance requirements are applied as constraints to these characteristics by linking the items in the database and defining ranges of values for the performance characteristics that should not, or may not, be exceeded.

Analyses

Analyses are run on state models that are sets of interconnected diagrams at appropriate levels in the architecture.

A state model can have external loads applied to it to represent different usage scenarios. An analysis can contain many such environmental loads. The environmental loads are defined as values of any of the performance characteristics at the external input(s) to the model.

Each analysis applies the environmental load and calculates performance characteristics for all of the symbols in the state model’s diagrams using the formulae and constraints in each symbol. The results are therefore quantitative. They are stored inside the symbols’ descriptions.

The results can be reported in the same manner as other information in a Cradle database. They can also be graphed. The graphs will typically show the values of specified characteristics along a path through the model, termed a thread. Each graph will show any constraints applied from the system requirements and the effect of the constrains on the analysis results. The data in such graphs can be exported to CSV.

Any number of thread analyses can occur.

The results will show that an architecture is viable if none of its constraints are violated.

Since the performance data is built into the architecture model, any changes to the model’s topology (such as a change to the architecture) will be automatically reflected in changes to the performance results. This allows easy comparison between alternative architectures.

The analysis results are the characteristics of a viable architecture. Hence, they are the constraints or budgets for the next level of design. So the analysis of each level produces performance constraints for the next level. This process can continue through the design levels until the system behaviour is sufficiently defined for simulation to be practicable.

Feature Summary

Please contact 3SL for further information about adding a Cradle PERF module to your existing system.

8th September 202313th June 2023

Cradle Modules – SYS

Cradle-SYS Module

The Cradle SYS module provides an analysis, process, architecture and design modelling environment that, being linked into the systems engineering lifecycle, provides full traceability and coverage for all model information. You can use SysML, UML, ADARTS, SASD, eFFBD, IDEF, BPM and other notations to achieve your MBSE goals.

Models

A model is an abstraction of an aspect of a system being developed. Therefore, models should not be separate from the needs, goals and objectives that the model seeks to satisfy, nor from the tests that validate the system’s compliance. Hence Cradle integrates modelling into all requirements and other systems engineering data, so every component of every model is traced to the highest level user need and to the lowest level test result.

This applies to agile and phase-based processes. An agile process has no less need for models simply because its iterations are short. To neglect rigorous design in agile projects will ultimately compromise the system if a clear design is not modelled at the outset and maintained through each iteration.

Domains

Each Cradle database provides analysis and design domains. Each domain can contain any number of models, optionally organised in hierarchies. Models can be used to represent concepts such as:

Alternative missions in a CONOPS
Products within a range
Regional variants of a product
Comparative analysis of architectures

Each model contains any number of diagrams from a wide variety of notations. Each diagram contains symbols, and each symbol is described by a data definition or specification.

All diagrams, specifications and data definitions in a model can be cross referenced to each other and to information in all parts of the lifecycle. So user requirements can be linked to use cases, that are linked to system requirements, that link to a logical model of system behaviour, that can be allocated to a logical architecture, which in turn can be allocated to multiple physical architecture models for assessment.

A System Breakdown Structure (SBS) is useful as an abstraction of the system composition, and as a single structure to which all the requirements can be linked. The alternative system architectures and designs can be explored, each in its own model, all models linked to the SBS. This simplifies traceability for the requirements and the performance constraints, without restricting the modelling activities.

Models can link to a Product Breakdown Structure (PBS) to allow linking to a PLM environment.

Diagram Notations

Cradle has over 20 diagram notations from methods including UML, ADARTS, IDEF, SASD, SysML and data, process and architecture modelling. The notations can be combined when semantically viable. Cradle does not limit you to one method, nor constrain your choices for the notations that will best express the system for the audience of that model.

Cradle provides a consistent, interface to building diagrams. It includes time-saving features to build diagrams in time-sequenced notations, such as Process Flow Diagrams (PFDs) and extended Function Flow Block Diagrams (eFFBDs).

In hierarchical notations, Cradle has a range of features to build both child and parent diagrams that are automatically consistent.

Consistency Checking

Cradle enforces diagram syntax when editing. Completeness and I/O consistency checks are provided, both within a diagram and between diagrams to ensure conservation of data and function. Cradle can also check the consistency of diagram graphics and text descriptions. For notations that use it, Cradle provides a full Data Dictionary with a formal BNF notation to describe data composition.

Bitfields

In architecture models, Cradle supports data protocol descriptions across interfaces and can generate message formats (bitfields) that describe the formatting of the messages in all data exchanges.

Symbols

Diagram symbols can be coloured and have embedded graphics, to ease users’ understanding of the model.

Notations and Models

Notations can be combined, such as using UML and other diagrams in the same model. Some notations can be used in many contexts. For example Sequence Diagrams (SQDs) can show a message protocol across an architecture model interface, their role in SDL before their use in UML.

All model elements can contain graphics, video, figures, tables, equations, URLs and integrate with desktop tools including Visio, Word, and Excel. Each diagram, data definition or specification is an item in the database and so can contain any number of attributes each containing, or referencing, up to 1 TByte of any type of data.

Configuration Management

Models have change histories, discussions, comments, are formally reviewed in Cradle’s CM system, and can be baselined.

Reports

Models can be printed to a variety of devices. They can be part of user-defined documents with requirements, tests and any other information. Models can be published into static, hyperlinked websites that provide links between diagrams and between symbols and the descriptions. All Cradle web UIs support viewing and navigation of models.

Import/Export

Models can be loaded from other tools by import or data conversion from other tools’ data formats or XML.

Feature Summary

Please contact 3SL for further information about adding a Cradle SYS module to your existing system.

31st August 202329th August 2023

Cradle Modules – DASH

Cradle DASH Module

The Cradle DASH module provides the means to define Key Performance Indicators (KPIs) . It also provides the means to define their presentation as dashboards in web UIs, non-web UIs and reports.

Every project uses a process to create, review and publish its objectives, operational concept, sets of requirements, architecture and design models, and other systems engineering data. These processes will include:

Management reporting
Quality checks
Routine audits

of the volume of work completed, and the completeness and quality of this work.

Key Performance Indicators (KPIs)

KPIs are measures of the maturity of the information managed in the process, and therefore of the process itself.

Cradle supports KPIs as a convenient means to provide an overview of the status of an entire project, or any phase.

Any number of KPIs can be defined. Each KPI is a calculation based on one or more elements of one or more metrics:

Product
Sum
Difference
Deduction
Proportion
Percentage

combined to produce a single numerical value. The component values are derived from user-defined queries, that are searches of database items, or searches of the links between these items, or both. The component metrics can:

Count the values or calculate the total, mean, average, range or variance of the values from the items found by the queries
Use values held in attributes or the results from user-defined calculation attributes
These calculation attributes can use other attributes of the same item (this includes other calculations) and also attributes from linked items, such as calculating the total cost from the individual costs of a parent and its children.

Any number of colour-coded range bands can be defined for each KPI so that its value can be shown in a block with an appropriate background colour.

Using colours for the KPIs allows the overall project status to be seen at a glance. Typically, anything shown in green is good, anything shown in red will need urgent attention, and anything yellow needs to be monitored carefully. It is easy to apply such traffic light conventions in a KPI’s colour bands.

Dashboards

A collection of KPIs is held in a dashboard. Any number of dashboards can be defined, either personal to you, shared with other members of your team, or shared with everyone in the project, or available to all projects.

Each dashboard presents its KPIs as a column with the KPI shown either as a name and colour-coded number:

or as a dial:

The size and display styles of the dials can be controlled for each KPI.

The dashboard can be published as a report, either as a table or as a set of dials. As for all reports, output can be to a file, a printer or the UI. Such dashboard reports are fully supported in web UIs, and non-web UIs.

Dashboard Output — Dashboard output to a report

The value shown in each KPI is a link. Selecting this value will display the list of items that have been used to create the KPI’s value.

Dashboards are shown in a separate sidebar in both web UIs and non-web UIs. One dashboard can be set as the default and can be shown automatically when the UI starts.

Custom web UIs could be created to show a collection of dashboards, for example to provide a simple overview of the project and more detailed analyses of the status of each work area.

Dashboards can be published to RTF, HTML and CSV files.

Feature Summary

Please contact 3SL for further information about adding a Cradle DASH licence to your existing system.

25th August 202313th June 2023

Cradle Modules – MET

Cradle MET Module

The Cradle MET module provides the means to define metrics on the:

Needs
Requirements
User stories
Features
Models
Tests

It also defines metrics on all other systems engineering data in your project. Metrics are ran to monitor your progress.

Each project uses a process to create, review and publish its: objectives, operational concept, sets of requirements, architecture and design models, and other systems engineering data. These processes include management reporting, quality checks and routine audits of the volume of work that has been completed, and the completeness and quality of this work.

Metrics are a means to measure characteristics of your project data by collecting information about the materials created at each stage in the process. For agile projects, these characteristics will be analysed at the start and end of each iteration or sprint, and in phase based processes, the analyses are likely to be weekly or monthly as part of normal project management activities.

Metrics are user-defined sets of calculations that can be run from the user-defined phase hierarchy and start pages, from the metrics tool’s own UI, as a report, or from a command-line utility.

You can collect metrics on any of your project data. This includes requirements, use cases, functions, architecture components, models, interfaces, issues, risks, features, test specifications, test results, verifications and any other information generated by the systems engineering process.

Metric Elements

Each metric contains any number of elements, each of which is the combination of a query that finds the information in the database to be analysed, and an analysis to be performed on this set of items found by the query.

Each metric element can use a simple query, or a complex query that nests one query inside another. The items found by the query can be counted, or the metric can perform a coverage analysis of the values of all of their category codes, or it can perform a calculation on the values of one or more attributes, including those attributes that are the results of other user-defined calculations. The results of these operations can be grouped in up to two levels based on the values of other attributes. You can also calculate weighted totals and means of a set of values. This can be used to calculate compliance of responses to a RTF or ITT. Basic calculations can be performed which are based on the results of other metric elements.

Pivot Tables

Metrics can also include pivot tables, which are a special tabular display using two of the items’ attributes’ values as rows and columns where the cells show the number of items from those found by the query that have each pair of values for these attributes.

If a pivot table is shown in the UI, the cells in the pivot table become links. Selecting a link displays the items that have that pair of attribute values. Thus, users can decompose the totals shown in the pivot table’s cells into lists of items with corresponding attribute values.

Running Metrics

The results of running a metric can be shown in Cradle web UIs and in the WorkBench UI. They can also be generated to RTF, HTML and CSV files and loaded directly into a variety of tools including web browsers, Word and Excel.

Metric Output — Metric displayed in WorkBench

Access to the metrics facility can be controlled, to ensure reliable metrics are produced only in project-approve contents.

This mechanism allows projects to monitor:

The completeness of sets of needs or requirements
The completeness of their cross reference linkage
The volume of data generated by specific project groups.

Metrics can be generated from any project baseline(s), allowing cumulative statistics to be created as the project develops. You can view the database as it was at the time of any historic baseline, and generate metrics from that baseline.

Metrics can be referenced from within KPIs in dashboards using the Cradle DASH module.

Feature Summary

Please contact 3SL for further information about adding a Cradle MET licence to your existing system.

24th August 2023

Using PDUIDs

This is the third in a short series of posts that explain Project Database Unique IDs (PDUIDs). This post explains how PDUIDs can be used in Cradle. The next and final post in the series will explain how PDUIDs can be controlled when information is moved between databases.

Opening Items

You can open an item by simply specifying its PDUID. You do not need to specify the type of the item using the Item Type Chooser dialogs in the WorkBench and web UIs. For items in models, you do not need to choose the correct domain and then locate the model inside that domain.

You simply specify the PDUID:

3SL Cradle PDUID Open Item by PDUID — Open Item by PDUID

The latest instance of the item will be opened.

Queries

You can find items based on their PDUIDs, or components of the PDUIDs, in addition to any other criteria that you may have set inside the query. Select the PUIDs tab in the Query Details dialog:

The selection of items by PDUID will return all instances that you can access RO or RW.

Specific PID

If you choose Specific PID then you can enter a PID and an optional UID range. If you only enter a PID, then the query will return all items whose PDUIDs contain that PID. This could be useful if you have been importing data from other databases and so the items in your database have PDUIDs with different PIDs.

For example, if you have separate databases that have different PIDs for:

Different missions in a programme, or
Different vessels in a class of vessels

and you have combined the data from several of these databases into one database, then this option will allow you to find only the items with a single PID, such as for a single mission or for a single vessel. You can optionally filter the items further by specifying a UID range. You can omit the leading zeroes from the UIDs.

Specific PUID

If you choose Specific PUID then you can enter a PUID (the PID and UID) and the query will return all instances of the item with that specific PUID that you can access RO or RW and subject to the other constraints in the query (such as returning only the latest instance that you may have specified in the ID tab).

PUID From

If you choose PUID from then you can enter a PUID (the PID and UID) and the query will return all instances of all items whose PUIDs are greater than the value you specified which will be the combination of:

All items with the same PID and whose UIDs are greater than your specified value
All items with PIDs greater than your specified value and any UID

that you can access RO or RW and subject to the other constraints in the query (such as returning only the latest instance that you may have set in the ID tab).

Referencing Data in Other Items

Items in a Cradle database can hold their information in any number of frames. Each frame is of a user-defined frame type that defines the characteristics of the frame. The data in frames of a frame type is normally stored in the Cradle database, but this can be controlled by the storage mechanism of the frame’s frame type:

In PDB	:	The frame’s data is stored in the Cradle database
As File	:	The frame’s data is stored in an external file whose pathname, size, last access and modified times are stored in the Cradle database
By Command	:	The frame’s data is held in an external environment under an identity, the database stores this identity, and uses Get and Set commands in the frame type to move the data between the environment (specified by the $IDENTITY *Command Directive) and a temporary file (specified by the $PATH* Command Directive) where it can be operated on. For example: Get: {unix cp}{win copy} “$PATH” “$IDENTITY” Set: {unix cp}{win copy} “$IDENTITY” “$PATH” This example exports the frame’s contents and sends to the application supplied in the frame type’s View or Edit command and saves the contents from the application back into the frame.
As Reference	:	The frame’s data is stored at a location outside Cradle and the frame stores this external location (such as a pathname or a URL). The data’s location is given to the frame type’s View command, which does not wait for this processing to complete – unlike in the other storage mechanisms.
Referenced File From Item	:	The frame’s data is held in a frame of a different item. The frame stores the PDUID of the other item whose data is being referenced (latest instance), and the name of the frame in this other item that contains the data. When the frame is accessed via a View command, Cradle opens the other item using its PDUID and copies the data from the referenced frame into a temporary file. This mechanism allows data in one item to reference data in another item, sharing the data between them.

Cradle URLs

Cradle URLs are URLs that can start a Cradle WorkBench client and either open an item or run a query. The action specified in a Cradle URL is executed by the c_url utility shipped in the Cradle clients. It can be run from a command line, an application, or a web browser that has been told about Cradle URLs (an option when Cradle clients are installed).

Cradle URLs are a way for another application to interface to Cradle. The other application can store Cradle URLs as, in effect, pointers to items in the Cradle database. When the user wants to access the Cradle item, the external application can either run c_url on the specified Cradle URL, or route it through a web browser that, in turn, will launch c_url.

Cradle URI Scheme

A URI scheme defines the structure of a URL. The Cradle URI scheme is:

cradle:[username][:password][;AUTH=authentication]@project[:access][?action&params…]

3SL Cradle URI Scheme — Cradle URI Scheme

by specifying a Cradle URL with the PDUID and instance details of the item to be opened.

Creating Cradle URLs

Cradle URLs can be created from the Tools tab WorkBench UI or any web UI. Once an item is selected:

3SL Create Cradle URL — Create Cradle URL

The Cradle URL shown in the dialog can be copied and pasted:

Into another application to provide a link to the selected item in Cradle
Into the c_url utility to execute the action in the URL
Into a web browser that understands the Cradle scheme, when it will launch the c_url utility to perform the requested action

API

Cradle has an Application Programming Interface (API) that supports both C/C++ and VB.NET. You can create any number of applications using the API. All of these applications will connect to the CDS in the same way as any non-web-based Cradle client supplied by 3SL (such as WorkBench or Document Publisher). Each of your applications can service one or many users. You need one API/WSI connection licence for every application that you want to concurrently connect to Cradle.

The API contains many routines. Collectively these routines provide facilities to create, read, update and delete both items and the cross references between them. The main data type for items is CAPI_ITEM_T which has components for both item identities and PDUIDs. The main data type for cross references is CAPI_XREF_T which contains the details of the cross reference but not the items that it connects. This is because cross references are not retrieved by themselves, rather the API returns a list of linked items each of which is a structure containing the CAPI_ITEM_T for the linked item and the CAPI_XREF_T for the cross reference by which it is linked. As such, the “from” and “to” items for a cross reference are implicit in the data structures.

A PDUID can be used to open an existing item using CAPI_Item_Open().

WSI

Cradle has a Web Services Interface (WSI) that supports a RESTful message protocol. You can create any number of applications using the WSI. All of these applications will connect to the Cradle Web Server (CWS) in the same way as any web-based Cradle client supplied by 3SL. Each of your applications can service one or many users. You need one API/WSI connection licence for every application that you want to concurrently connect to Cradle. Each of these connections can either be session-based or it can use message-by-message connections.

The WSI contains many operations. Collectively, these operations provide facilities to create, read, update and delete both items and the cross references between items. The data sent and received in these operations is packaged in JSON. These JSON packets contain full details of items and cross references and include both item identities and PDUIDs.

The WSI predominately uses PDUIDs as a means to specify items of information, and for links between items. For example using the curl command to send a HTTP message to a Cradle WSI session whose details are in the file cookies.txt to the CWS running on port 8015 at server myserver to get the contents of a database item into a local JSON file:

curl -X GET -b cookies.txt “http://myserver:8015/rest/projects/DEMO/items/16EC668D4ADEMO010000000907?fields=all” > myItem.json

and to update the same item in Cradle with new information added into the same local JSON file:

curl -X PUT -b cookies.txt “http://myserver:8015/rest/projects/DEMO/items/16EC668D4ADEMO010000000907” -d @myItem.json

18th August 202313th June 2023

Cradle Modules – DOC

Cradle DOC Module

The Cradle DOC module generates documents by combining user-defined templates with items in the database. A document register and a correlation between documents and database items provides full traceability.

Projects use documents:

As sources of information (such as user requirements or regulations, codes and standards)
As confirmation of agreement (such as a CONOPS or RTM or SRD)
To define interfaces between project teams or organisations (such as a SDS or SSDS).

Often, a project’s progress can be expressed as the issue states of its key documents.

User Defined Reports

Cradle can generate user-defined reports that will satisfy all internal project needs for information, including:

Simple lists
Compliance tables
Change logs
Traceability
Coverage matrices

These outputs are produced from the report, view, query and matrix facilities of the Cradle-PDM module.

The Cradle Document Generation module exists to produce complete, high quality, documents directly from the database. It can publish documents that include cover pages, Table of Contents, List of Figures, sections with mixtures of hierarchical paragraphs, bullet lists, figures and tables.

Defining Documents

Any number of documents can be defined. Each starts as a Microsoft Word document that has all of the internal structure, page layouts, styles and formats required. The Document Publisher tool is used to insert tags into this template everywhere that data is to be reported from the database. Each tag defines both the information to be published, and the high-level formatting to be used for this information, for example if it is to be published as a hierarchy of sections, a bullet list, or as rows in a table. The tags can follow cross references in any manner required, so complex relationships can easily be included in the document. The tags are defined through a UI, so that complex scripts are not needed.

Arbitrarily complex tables, hierarchies of sections and subsections, embedded diagrams, paragraph and section numbering and self-referencing within the document are supported, all specified within these tags and their associated descriptions.

At runtime, the Document Publisher uses the tags to query the database for information that is to be loaded into Word and formatted according to the styles, contents lists and indexes of that Word template. Embedded binary data can be loaded into the document, including any other Word documents and other binary content, including figures, spreadsheet and drawings.

Document templates can include user-defined variables that are specified at runtime so that a single template can be used to produce many different documents.

Any number of these templates can be defined and each used to generate many documents. Each document publishing operation will report either the current work-in-progress information or the contents of project baselines created with Cradle’s built-in Configuration Management System.

Publishing Documents

Documents can be published from the Document Publisher tool’s UI, Start Page drop downs, from nodes in a user-defined phase hierarchy UI, or the command line. This allows Document Publisher to be run in batch mode, for example to publish standard project documents overnight.

When Document Publisher is used to publish a document from a template and the database, the resulting document can be marked as a formal document by specifying an issue, issue date and reference. In this case:

A copy of the published document is held in the database so it can be provided in the future
A record of the document is added into a formal document register, and
Cradle records which instances of database items were used to produce the document

This means that when anything changes in the database, you know which formal documents contain the items that have changed, so you know which formal documents need to be re-issued. The new version of these formal documents are also recorded in the register.

Comparison of the contents of different issues of project documentation and the items published within them, are fully supported.

Published documents can be provided to customers and suppliers. They can also be captured using the Document Loader tool, after an external group has made change. So cyclical processing of external documents is supported. When combined with the register of the issue states of project documents, this facility means that all document-orientated processes are supported. The tools therefore fully support all customer-supplier and supply chain management contexts.

Feature Summary

Please contact 3SL for further information about adding a Cradle DOC module to your existing system.