actif workshop - how - 02

Download ACTIF Workshop - How - 02

Post on 19-Jul-2016

216 views

Category:

Documents

3 download

Embed Size (px)

DESCRIPTION

actif

TRANSCRIPT

  • The FRAME Architecture - "How"

    FRAME Team 1

    The FRAME ArchitectureHow

    Peter Jesty and Richard BossomFRAME Team

    Presentation to ACTIF TeamParis, 23 September 2013

    FRAME Team ACTIF Team Presentation, Paris September 2012 2

    Contents ofThe FRAME Architecture

    FRAME Team

    The FRAME Architecture Comprises

    A set of User Needs

    With cross-references to

    A Functional Viewpoint

    Methodology

    Data Flow Diagrams

    Functions, Data Stores and Data Flows

    Terminators (the outside world)

    Descriptions of each element

    ACTIF Team Presentation, Paris September 2012 3 FRAME Team

    Why Use Data Flow Diagrams?

    Have the required properties for a Framework Architecture

    Sub-sets can be created easily

    Easily understood by ALL ITS Stakeholders

    ACTIF Team Presentation, Paris September 2012 4

  • The FRAME Architecture - "How"

    FRAME Team 2

    FRAME Team

    User Needs

    Provide the formal description of all the ITS applications and services include in the FRAME Architecture

    Structured to make it easy to find the User Needs for a particular application or service

    Available in textual format from the FRAME website

    www.frame-online.net

    ACTIF Team Presentation, Paris September 2012 5 FRAME Team ACTIF Team Presentation, Paris September 2012

    Scope of the User Needs

    6

    FRAME Team

    User Needs Group 1

    Covers the non-functional requirements

    Checklist for system specifications

    Data Exchange Maintainability

    Adaptability Quality of Data

    Constraints Safety

    Cost/Benefit Security

    Expandability User Friendliness

    Special Needs

    ACTIF Team Presentation, Paris September 2012 7 FRAME Team ACTIF Team Presentation, Paris September 2012 8

    Context Diagram

    System Boundary

    Different Viewpoints

    Terminators

  • The FRAME Architecture - "How"

    FRAME Team 3

    FRAME Team ACTIF Team Presentation, Paris September 2012 9

    Setting the System Boundary

    System Boundary is shown by the Context Diagram

    Usually architecture creators must decide:

    What to include?

    Too much can be complex, may involve lots of organisations

    Must be able to influence what is included

    What to leave out?

    Too little interfaces not properly defined, technical islands may appear outside

    May not be able to influence what is left out

    The FRAME Architecture has done this for you

    FRAME Team ACTIF Team Presentation, Paris September 2012 10

    Terminators

    A Terminator can be a person, organisation, or another system

    A Terminator has a description

    States what is expected of the Terminator

    The European ITS Framework Architecture has 22 generic Terminators

    Each represents one or more of the class of person, organisations or system mentioned

    Many generic Terminators comprise Actorswhen necessary

    FRAME Team ACTIF Team Presentation, Paris September 2012 11

    Actors

    Some Terminators need to distinguish between different classes/types of that Terminator

    Terminator acronym : {driver} d Actor acronym: {driver}.{freight vehicle driver} d.fvd

    DriverTerminator

    PrivateDriver

    HazardousFreightVehicleDriver

    PublicTransportDriver

    FreightVehicleDriver

    EmergencyVehicleDriver

    Actor

    FRAME Team ACTIF Team Presentation, Paris September 2012 12

    The Terminator Other Related System

    A link to other instances of Systems that have been produced using the European ITS Framework Architecture

    Other Related System

    Traffic Management System A

    Traffic Management System B

  • The FRAME Architecture - "How"

    FRAME Team 4

    FRAME Team ACTIF Team Presentation, Paris September 2012 13

    The Terminator Multi-Modal System

    Links with systems that manage the transportation of Travellers and Freight by modes that are other than those that are road based

    Multi-Modal System

    Multi-Modal Management

    System

    Multi-Modal Crossing

    Other Mode Freight System

    FRAME Team

    Functional Viewpoint

    Contains all the functionality needed to fulfil the User Needs

    The relationship between the Functionality and the User Needs is built into the FRAMEArchitecture

    Structured to group the functionality of similar things together

    Available from the FRAME websitewww.frame-online.net

    ACTIF Team Presentation, Paris September 2012 14

    FRAME Team ACTIF Team Presentation, Paris September 2012 15

    Functional Areas

    Functional Viewpoint has the following 9 Functional Areas1: Provide Electronic Payment Facilities

    2: Provide Safety and Emergency Facilities

    3: Manage Traffic

    4: Manage Public Transport Operations

    5: Provide Support for Host Vehicle Systems

    6: Provide Traveller Journey Assistance

    7: Provide Support for Law Enforcement

    8: Manage Freight and Fleet Operations

    9: Provide Support for Cooperative Systems

    There is not a direct one-to-one relationship between the User Needs Groups and the Functional Areas Not the problem that it might at first seem!

    FRAME Team ACTIF Team Presentation, Paris September 2012 16

    Functional Areas

    Highest level of decomposition are the Functional Areas

    FRAME Architecture split into 9 Areas

    Manage the complexity

    FRAME V4.1 has

    ~310 Low Level Functions

    ~2150 Data Flows

    Logical split of functionality

    Originally developed separately

    Minimum data flows between them

  • The FRAME Architecture - "How"

    FRAME Team 5

    FRAME Team ACTIF Team Presentation, Paris September 2012 17

    Functional Decomposition

    Splits-up the Functions into different groups:

    Structures them in a hierarchy

    Done for two reasons

    For diagrams

    Difficult to place >10 Functions on a single diagram

    And to show the resulting data flows

    For later use in Physical Viewpoint

    Only the lowest level Functions are used

    Functions exist in a location

    Need to split them to provide flexible types of deployment

    FRAME Team

    Data Flow Diagrams

    ACTIF Team Presentation, Paris September 2012 18

    Function

    Data Flow

    Data Store

    FRAME Team ACTIF Team Presentation, Paris September 2012 19

    How to create your own sub-set

    The FRAME Methodology

    FRAME Team

    The complete ITS Architecture Creation Process

    ACTIF Team Presentation, Paris September 2012 20

    Stakeholder

    Aspirations

    User Needs

    Functional

    Viewpoint

    FRAME

    Architecture

    Communications

    Viewpoint

    Physical

    Viewpoint

    Relationship

    Relationship

    Relationship

    Relationship

    and

    Feedback

    Results of Stakeholder

    Consultations

    Organisational Issues

    Deployment Plan

    System Boundary

    Cost/Benefits

    Risk Analysis

    Component

    Specifications

    and

    Communications

    Requirements

    Procurement Process

    Relationship

    Relationship

    and

    Feedback

  • The FRAME Architecture - "How"

    FRAME Team 6

    FRAME Team

    ITS Architecture Creation ProcessUser Needs

    ACTIF Team Presentation, Paris September 2012 21

    Stakeholder

    Aspirations

    User Needs

    Functional

    Viewpoint

    FRAME

    Architecture

    Communications

    Viewpoint

    Physical

    Viewpoint

    Relationship

    Relationship

    Relationship

    Relationship

    and

    Feedback

    Results of Stakeholder

    Consultations

    Organisational Issues

    Deployment Plan

    System Boundary

    Cost/Benefits

    Risk Analysis

    Component

    Specifications

    and

    Communications

    Requirements

    Procurement Process

    Relationship

    Relationship

    and

    Feedback

    Provides the formal descriptions for all of the ITS services that the FRAME Architecture includes

    Structured to make it easier to find the User Needs for particular services

    Stakeholder Aspirations are mapped to User Needs from the ITS Framework Architecture

    FRAME Team

    ITS Architecture Creation ProcessFunctional Viewpoint

    ACTIF Team Presentation, Paris September 2012 22

    Stakeholder

    Aspirations

    User Needs

    Functional

    Viewpoint

    FRAME

    Architecture

    Communications

    Viewpoint

    Physical

    Viewpoint

    Relationship

    Relationship

    Relationship

    Relationship

    and

    Feedback

    Results of Stakeholder

    Consultations

    Organisational Issues

    Deployment Plan

    System Boundary

    Cost/Benefits

    Risk Analysis

    Component

    Specifications

    and

    Communications

    Requirements

    Procurement Process

    Relationship

    Relationship

    and

    Feedback

    Contains all the functionality needed to fulfil all the User Needs

    Also structured to group functionality for similar things together

    Relationship between functionality and User Needs built into the FRAME Architecture

    FRAME Team

    ITS Architecture Creation ProcessPhysical Viewpoint

    ACTIF Team Presentation, Paris September 2012 23

    Stakeholder

    Aspirations

    User Needs

    Functional

    Viewpoint

    FRAME

    Architecture

    Communications

    Viewpoint

    Physical

    Viewpoint

    Relationship

    Relationship

    Relationship

    Relationship

    and