DOC

Cradle Newsletter - August 2003

By Geraldine Hicks,2014-04-13 02:31
6 views 0
You can represent the physical structure of the system as a hierarchy of items. To provide the information for system design documents (SDSs); To provide the information Set an auto-incrementing value into the item's attribute

?Cradle August 2003 Newsletter

     From concept to creation… www.threesl.com

    The premier systems engineering environment

    3SL Newsletters

    These newsletters provide details of 3SL products and services, and information on

    general requirements management and systems engineering topics.

    3SL Website

    We continually develop the content of the 3SL website, with its descriptions, topics,

    manuals, downloads, its reference and on-line support for Cradle. Recently, we In this issue: have extended the range of support software available in the Downloads section and

    have simplified its layout. 1. 3SL

    Newsletters As ever, the easiest way to get the latest Cradle software is: download it!

    2. 3SL Website Visit www.threesl.com and create your login account now!

    3. Need Help? ? If you need help creating a login account, or want more information, click here

    ? To be nominated as a Cradle customer, create your account, then e-mail 3SL 4. Training

    support by clicking here, and be sure to tell us your login username Courses

    ? To be nominated as a Cradle site representative, create your account, e-mail 3SL 5. Architectures support by clicking here, and be sure to tell us your login username 6. Architecture

    Modelling

    7. Architecture Need Help? Interconnect

    Diagrams If you have any problems with your Cradle system or evaluation we want to hear from

    you! E-mail our support team by clicking here. 8. Physical

    Architecture We can offer support direct to your desktop through a webinar, all you need is a PC with

    Diagrams a web browser and Internet access.

    9. Requirements If you’ve a problem, we can display one of our Cradle systems directly onto your Parsing desktop, or yours onto ours (if you allow it). You can then show us the problem by

    driving this Cradle system, and we’ll show you how to fix it! 10. Diagram Print

    Options We can set up these webinars instantly, at any time, so please don’t struggle with a

    problem, get in touch with us and we can solve it together! 11. CSV Import

    12. Capturing

    from Word Training Courses Tables 3SL provides a range of tailored training courses for Cradle. These courses are 13. Capturing assembled to meet your specific needs form a range of training modules in a wide from Excel range of subject areas, at Introductory, Advanced and Supplemental levels.

    Each module is self-contained and is designed to last approximately one hour. All

    modules are supplemented by appropriate interactive hands-on sessions devised by the

    course instructor.

    These modules are typically assembled into 1, 2 or 3-day training courses, each day

    typically using 6 of the modules. Training courses are delivered in your offices using

    your equipment (3SL can provide training PCs) and are priced per training day for up to

    8 students. Larger class sizes can be accommodated by prior arrangement with 3SL.

    You will shortly be able to view details of the latest Cradle training course modules

    through our website. This material will be available in a new Training section in the

    Support area of the website. It features a tabular presentation of the available modules,

    grouped by subject area and by level. Selecting links in this table will lead you to a page

    describing that module, containing the course module’s:

    ? Description

    ? Objectives

    ? Contents

    Check our website after 8

    th September to browse this new material!

    Architectures

A crucial aspect of any system is its architecture, the physical elements from which the

    system will be built and the interconnections between them. You can represent the

    physical structure of the system as a hierarchy of items. This is normally called the

    System Breakdown Structure, or SBS. You can also represent the structure of the

    platform (the aircraft, ship, vehicle and so on) and then the system within it. This is

    normally called the Physical Breakdown Structure, or PBS. Both the SBS and PBS may,

    in practice, be more than a simple hierarchy, to allow for common components at any

    level.

    The PBS normally corresponds to the Bill of Material (BoM) for the system, such as will

    be found in, and manipulated by, a Product Data Management (PDM) or Electronic

    Data Management (EDM) system. These are the systems that normally back-end to a company’s CAD and CAM systems.

    In this sense, the representation of the PBS in the systems engineering tool is often used to initialise the BoM in the PDM system, and later is updated form the BoM as it

    matures. The PBS items in the systems engineering tool will include part numbers,

    descriptions and often associated weights, sizes and references to the applicable engineering drawings. The PBS will reflect the physical structure of the platform, such

    as its compartments, zones, major and sub-assemblies, although they will not normally

    contain actual position or coordinate information, nor precise sizes, other than the location within a particular compartment or zone.

    A major element of the organisation of the PBS will be to represent the FRUs (field

    replaceable units) from which the system is composed. This is to allow each of these

    FRUs within the PBS to be linked to associated test specifications and reports. The distinction between the SBS and PBS is normally a matter for the project. Both will

    not always exist. A project may decide that a SBS can fulfil the role of the PBS as

    described above, and may not construct both.

    Where both are constructed, the distinction between the SBS and the PBS is typically

    either:

    ? That the SBS corresponds to logical components consisting of collections of

    hardware and/or software functions, whilst the PBS consists of the physical

    components

    ? That the SBS is a grouping of physical components that are more related to the

    designers’ ideas of system and subsystem, and the PBS is the physical collection of

    equipments, assemblies, sub-assemblies, components and parts The PBS and SBS will occur at different times and have different purposes. The SBS is

    produced first, and as a means of representing the architecture, its major aims are:

    1. To define the system’s constituents

    2. To define the functionality contained within each constituent 3. To define the connections between these constituent 4. To define the data flow across these connections and the protocols for such data

    exchanges

    5. To define the interfaces at the ends of these connections 6. To define the data, electrical and physical characteristics of these interfaces 7. To provide the information for system design documents (SDSs) 8. To provide the information for interface control documents (ICDs) 9. To allow performance assessments to be made of the system or subsystems 10. To allow fault tree and FMECA (failure mode, effect and criticality analyses) to be

    conducted on the system, subsystem and equipments’ designs The PBS evolves later. Its aims are:

    1. To describe the platform’s physical structure

    2. To describe the system’s physical constituents

    3. To define the positions and mountings of the system constituents within the platform

    physical structure

    4. To support weight, power distribution, thermal stress, physical shock, vibration

    corrosion and noise analyses

    5. To support damage analyses, including fire, water, radiation and (for military and

    defensive applications) EMC pulse and explosion penetration, lethality and

    containment

    6. To produce manufacturing, assembly and disassembly drawings 7. To support procurement, logistics and Materials Resource Planning (MRP) 8. To allow the design of manufacturing jigs and specialist assembly tools 9. To allow the production of Computer Aided Manufacture (CAM) data, especially for

    CNC tools

    10. To produce maintenance and upkeep manuals

    The architecture is the combination of the SBS and the PBS, where both are built. As described, the SBS is primarily an engineering tool, whereas the PBS is primarily a

    manufacturing and support tool.

    As an engineering tool, the SBS as described is rather limited. As a hierarchy of items

    (or even as a more complex structure of items), the designers’ ability to visualise the

    system is limited. In practice, most engineers will draw box-and-line diagrams sooner or later to describe the SBS.

    These box-and-line diagrams allow engineers and customers to visualise the two- and three-dimensional logical structure and connections more easily. One or more such

    diagrams are commonly called an architecture model.

    Architecture Modelling

    Cradle provides two modelling domains:

    ? Essential, for building implementation-independent analysis models ? Implementation, for building implementation-dependent design models Each domain can contain multiple models. Each model can be built from any

    combination of the diagram notations and associated symbol definitions that Cradle

    provides.

    You can build any number of architecture models in the Implementation domain of a

    Cradle project. One model is usual, but others may be required to reflect either: ? Alternative designs

    ? The use of different mandated or COTS (commercial off the shelf) equipment Architecture models are built with respect to:

    ? Non-functional user requirements

    ? Non-functional system requirements

    ? Specific mandated and COTS equipments

    ? Previous system designs

    They are built to:

    1. Define the physical elements of the system

    2. Define the interconnections between these elements, the interfaces 3. Identify and characterise the data exchanges through the interfaces, often as a set

    of messages and an associated message protocol

    4. Allow the functionality to be identified for each element of the architecture,

    potentially by allocating functionality through cross references to an implementation-

    independent analysis model

    5. Allow a System Design Specification (SDS) to be built for the system 6. Allow the production of Sub-System Design Specifications (SSDSs) for the

    system’s subsystems, particularly important when these subsystems are to be

    subcontracted

    7. Allow Interface Control Documents (ICDs) to be built for each system interface,

    particularly Interface Specifications (IFSs) and Data Exchange Specifications

    (DESs)

    8. Allow performance assessments and simulations to be conducted to optimise the

    characteristics of the components in the architecture 9. Allow appropriate integration and system-level test specifications to be built

    10. Allow a mapping to either or both of a Product Breakdown Structure (PBS) and

    System Breakdown Structure (SBS)

    Architecture models to be created from either of two notations: ? Architecture Interconnect Diagrams (AIDs) ? Physical Architecture Diagrams (PADs)

    The symbology and semantics of these two diagrams are similar. Both notations have been devised by 3SL, based on our experience with customers’ practical applications in

    a wide range of systems engineering projects. An architecture model can use either or both of these notations. Whichever are used,

    the usual topology is for the Implementation domain to use the architecture model(s) as

    a means to group related functionality into physical components. The Implementation

    domain is therefore layered, with architecture model(s) at the top, and function or UML

    design models underneath. The architecture model will be linked to: ? Non-functional user requirements

    ? Non-functional system requirements

    ? Subsystem, system and integration tests

    whilst the design models are linked to:

    ? Analysis models, if they have been built

    ? Functional user requirements (if no analysis models) ? Unit and module tests

    Architecture Interconnect Diagrams The AID is intended to depict architectures in a manner similar to freehand box-and-line

    diagrams.

    The AID shows parts of the system and the flows of data between them. In this sense, the AID is partly physical and partly logical. It is physical in that it shows physical

    equipments and components of the system. It is logical in that it shows the data and

    control flowing between these physical items, and not necessarily the physical

    connections by which this data and control flows. Thus an AID would:

    ? Not necessarily show buses, where buses are used ? Show individual connections for related groups of data, instead of showing physical

    cables that may carry several such groups AIDs can be used to show buses, and can be used to show physical connections, but

    this is contrary to their primary emphasis, which is: ? Physical components

    ? Information flows between these components The AID provides a range of symbols to show: ? Elements of the system environment

    ? Decomposable (hierarchical) rectangular, triangular or circular components

    ? Non-decomposable rectangular, triangular or circular system elements

    ? Signal links for low volume control signals ? Signal channels for high volume control signals ? Data links for low volume data links

    ? Data channels for high volume data links

Projects can choose whether to use the components or elements, and can choose a

    convention for the use of the various symbol shapes.

    Using component symbols allows hierarchies of AIDs to be created to show the full

    structure of the SBS.

    Each component and element symbol can be defined by a specification that, being an

    item in the Cradle database, can contain any number of frames containing any type(s) of data. This allows such specifications to contain descriptions, performance or FMECA

    data, and external documents such as technical data sheets, manufacturer’s brochures

    or performance characteristics. These specifications can be cross referenced to any other project data.

    Each signal and data link and channel is defined by an entry in the Implementation

    domain Data Dictionary (DD). These DD entries describe the meaning or purpose of the

    connection, and the composition of the data within it. Such compositions can reference other, lower level, data definitions (to whatever level of detail and complexity are

    required) which would also be DD entries.

    To add allocated functions or classes to an AID component, it can be expanded into a lower level diagram. The connectivity options for AIDs are:

Physical Architecture Diagrams

    The PAD is intended to depict architecture in a purely physical manner. PADs show

parts of the system and the physical connections between them. It shows physical

    equipments and the physical connections between them. The PAD allows for reuse of physical components, by providing a shared equipment

    symbol that can be used any number of times on any number of diagrams. Wherever a

    particular shared equipment is used, it always has the same definition and the same

    diagram expansion.

    If a shared equipment is decomposed into its own PAD, this PAD shows the internal

    structure of the shared equipment. This diagram can itself contain equipment symbols

    which can, in turn, have their own expansion into other PADs or AIDs. This allows each

    shared equipment to be defined in its own equipment model. Furthermore, the diagrams in an equipment model can also contain shared equipment

    symbols, each of which can have their own equipment model. This allows a hierarchy of architecture and equipment models, with physical elements being reused at several

    levels in the SBS hierarchy:

Thus a PAD would:

    ? Show buses, where buses are used

    ? Show physical connections, such as physical cables, between equipments that will

    carry several such groups of related data

    The primary emphasis of PADs is:

    ? Physical components

    ? Information flows between these components The PAD provides a range of symbols to show: ? Elements of the system environment

    ? Decomposable (hierarchical) equipments

    ? Reusable shared equipments that have a common definition and decomposition

    ? Decomposable buses

    ? Links for physical connections

Using component symbols allows hierarchies of PADs to be created to show the full

    structure of the SBS.

    Each component and element symbol can be defined by a specification that, being an

    item in the Cradle database, can contain any number of frames containing any type(s)

    of data. This allows such specifications to contain descriptions, performance or FMECA data, and external documents such as technical data sheets, manufacturer’s brochures

    or performance characteristics. These specifications can be cross referenced to any

    other project data.

    Each link is defined by an entry in the Implementation domain Data Dictionary (DD). These DD entries describe the meaning or purpose of the link, and the composition of

    the data within it. Such compositions will typically be sets of messages, where each

    message would also be a DD entry, whose composition would be the data items in the message, themselves also further DD entries.

    To add allocated functions or classes to PAD equipments, they can be expanded into lower level diagrams. The connectivity options for PADs are:

Requirements Parsing

    The Cradle-REQ module has a Source Document Manager (SDM) tool that allows: ? Registering source documents with Cradle

    ? Capturing requirements (or other types of item) from such documents using a

    controllable parser

    ? Creating cross references between such captured items and the corresponding

    source statements in the source documents

    ? Registering new versions of such source documents

    ? Automatically identifying differences between the source document new and old

    versions

    ? Automatically updating the cross references between source documents and

    captured items in the database

    When capturing requirements (or other items) from the source document, the SDM uses

    a parser. The parser works on ranges of text, where a range is either: ? A paragraph

    ? A sentence

    ? A line of text

    ? A word

    Paragraph ranges are the most common, you define to the form of the paragraphs in

    your source document to the parser, and it will then locate and highlight successive

    paragraphs as you scan the source document. Once a range is highlighted, you can

    define a set of capture operations that will be performed to perform the capture of an

    item into the database from the contents of the selected range. Each capture operation in this set identifies a value for a single attribute in the item

    (such as a requirement) being captured. There are many options for these operations: 1. Set a fixed value into the item’s attribute

    2. Set one of the source document’s details into the item’s attribute 3. Set an auto-incrementing value into the item’s attribute

    4. Set a fixed value of a category code into the item’s category attribute 5. Perform auto-categorisation to determine a value for the item’s category attribute,

    where auto-categorisation means to scan the selected range to find matches for

    any of the set of Category Recognition Strings (CRSs) for each category value

    (such as the CRSs strings must, will and shall for the value Mandatory in a Priority

    category); these CRSs can be regular expressions

    6. Extract a substring from the selected range according to start and end regular

    expressions and use the text between them as the item’s attribute value 7. Find a substring from the selected range that matches a specified regular

    expression and use the matching text as the item’s attribute value 8. Set the remaining text from the selected range into the item’s attribute value 9. Copy an item attribute value into another attribute of the same item These options provide a powerful and flexible mechanism for capturing multiple

    attributes of items from the contents of source document paragraphs. For example, the

    following set of capture operations will load the specified attributes from the following

    paragraph format:

    1. Cut paragraph number and store in requirements’ Key attribute 2. Cut text from within [ and ] and store as requirements’ Security Classification 3. Cut remainder of first line and store as requirements’ Name attribute 4. Cut text from within ( and ) at end of text and store as requirements’ Number 5. Scan rest of text and automatically derive value of Priority attribute (would be set to

    Mandatory as this example includes the word shall) 6. Put remaining text into requirements’ TEXT frame Diagram Print Options

    Once you have created a set of capture operations that is suited to a given style of The Diagram Editor (DGE) can print diagrams to any of Cradle’s supported output source document, you can store this set of capture operations in a personal or project-device types, which are: wide file, allowing you to re-use them whenever necessary. ? Epson LQ (rasterised bitmaps)

    ? EPS (Encapsulated PostScript)

    ? EXPRESS

    ? FrameMaker (MIF format)

    ? HPGL

    ? HP LaserJet (rasterised bitmap)

    ? PostScript

    ? Proprinter (rasterised bitmap)

    ? RTF (for Word)

    ? SVG (for web pages)

    When printing from the DGE, you can either print just what is visible in the current DGE

    session, or the whole diagram. Whichever option you choose, the resulting diagram (or diagram part) is automatically scaled to fit within the available print area. This print area

    is determined by your current paper size, and the number of sheets of paper over which

    the diagram is to be printed.

    To ensure that you can always choose what is printed, print the DGE session’s contents

    by selecting File?Print, or press CTRL+P to display the Print Diagram dialogue:

CSV Import

    Comma separated value (CSV) files are a simple and flexible way to exchange data

    between applications. Most database applications support CSV files as do many

    requirements management and systems engineering tools, including Cradle, Excel,

    DOORS, FileMaker, Access, Oracle and RTM.

    The format of CSV files is very simple:

    ? Each file is a sequence of records, each ending in a LF (linefeed) or CRLF

    ? Each record contains a set of fields, separated by commas ? All records contain the same number of fields

    ? The first record in the file may contain the names of the fields ? If a field contains a , (comma) character, then it is surrounded by " (double quote)

    characters

    ? If a field contains a " (double quote) character, then it is escaped by being

    represented either as "", or as \"

    Cradle can export most data from a project database in CSV format, and can import

    data in CSV format into most item types in the database, including: ? Requirements

    ? Events

    ? Specifications

? DD entries

    ? User defined items

    ? Cross references

    When importing CSV data, you must define a mapping between the fields in the CSV file and the attributes of the database items that you are importing into:

    Cradle provides an Overwrite option with three values: ? Off

    ? On

    ? Merge

    that controls whether and how data from the CSV file is loaded into the database.

    With overwrite = off:

    ? If item exists, import does not occur

    ? If item does not exist, import occurs

    ? All attributes in import file are set into database item With overwrite = on:

    ? If item exists, import occurs

    ? If item does not exist, import occurs

    ? All attributes of item in import file are set into database ? Attributes in database item not in import data are lost:

With overwrite = merge:

    ? If item exists, import occurs

    ? If item does not exist, import occurs

    ? All attributes of item in import file are set into database ? Attributes in database item not in import data are kept:

Report this document

For any questions or suggestions please email
cust-service@docsford.com