actif workshop - how - 02

The FRAME Architecture - "How"

© FRAME Team 1

The FRAME Architecture“How”

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


© 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


© FRAME Team 3


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


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


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


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


© FRAME Team 4


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



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!


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


© FRAME Team 5


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


Function

Data Flow

Data Store


How to create your own sub-set

The FRAME Methodology

© FRAME Team

The complete ITS Architecture Creation Process


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


© FRAME Team 6

© FRAME Team

ITS Architecture Creation ProcessUser Needs


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


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


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


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


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


Deployment Plan

System Boundary

Cost/Benefits

Risk Analysis

Component

Specifications

and

Communications

Requirements

Procurement Process

Relationship

Relationship

and

Feedback

Shows Components needed to implement Stakeholder Aspirations

Each Component may contain one or more functional elements and is assigned to a physical location

Component Specifications are available for use in procurement

© FRAME Team

ITS Architecture Creation ProcessCommunications Viewpoint


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


Deployment Plan

System Boundary

Cost/Benefits

Risk Analysis

Component

Specifications

and

Communications

Requirements

Procurement Process

Relationship

Relationship

and

Feedback

Identifies the communication links between Components

Enables communications requirements for each link to be defined

Any standards that are applicable to each link can be identified


© FRAME Team 7

© FRAME Team

Stakeholder Aspirations


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


Deployment Plan

System Boundary

Cost/Benefits

Risk Analysis

Component

Specifications

and

Communications

Requirements

Procurement Process

Relationship

Relationship

and

Feedback


ITS Vision

• Describes the main “goal” that the ITS implementation will fulfil

• Useful because it:

– Provides a focus for the ITS implementation

– Helps Stakeholders to decide on how they could be affected

• It may need to be refined once the Stakeholders have defined what they want the service to deliver


Stakeholder Involvement

• Stakeholders are people & organisations:

– Affected by ITS deployment

– Involved in ITS deployment

• Four types of Stakeholder, those who:

– Want ITS – Local Authorities, Road Operators

– Make ITS – Component Suppliers, Comm’s Providers

– Use ITS – Travellers, Freight Shippers

– Rule ITS – National Governments, EU, Standards

• Service Providers may be “Want”, “Make”

and/or “Use”

• All expect different things from ITS deployment



• Enables Stakeholders to define the services that they want ITS to deliver

• Aspirations must be:

– Produced using Stakeholder consultation

– Written in a way that Stakeholders can easily understand

– Agreed by Stakeholders and published for all to read

– Presented to higher Authorities

• Crucial to success of the ITS Architecture and service delivery


© FRAME Team 8


Examples of Stakeholder Aspirations

There is a need for the TMC to be able to include bus information (e.g. bus service delays), especially during inclement weather (e.g. service suspended)

There is a need to develop pre-trip and on-trip traveller information systems to assist the traveller in making journey planning decisions, including the use of VMS, Internet and CCTV.

There is a need to improve the integration between the different modes of transport by providing improved cycle and pedestrian networks, through ticketing, and developing transport interchanges.

Re-produced by kind permission of Kent County Council, UK

© FRAME Team

User Needs


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


Deployment Plan

System Boundary

Cost/Benefits

Risk Analysis

Component

Specifications

and

Communications

Requirements

Procurement Process

Relationship

Relationship

and

Feedback

© FRAME Team

Selecting User Needs

• Select the User Needs from the relevant Topic(s)

• Not all User Needs within a Topic may be needed

– Check the description to confirm that it is actually required

• This task should be done “on paper” and the Selection Tool used to record the results

• Some User Needs may need to be added

– FRAME does not include every “one-off” application

– The User Needs are sometimes written at a high-level

• May need clarification at a lower level

ACTIF Team Presentation, Paris – September 2012 31 © FRAME Team ACTIF Team Presentation, Paris – September 2012 32

Extracting User Needs – Example

Aspiration - There is a need to improve the integration between the different modes of transport by providing improved cycle and pedestrian networks, through ticketing, and developing transport interchanges.

6.1.1.2 The system shall be able to provide trip information on other modes of transport, e.g. for demand-spreading, or when major events occur, or due to weather conditions, strikes, cultural or sports events etc.

6.1.2.2 The system shall be able to provide information on the cancellation of departures from a railway station, an airport , a port

or a coach station (due to the weather; strikes or other reasons).

6.2.1.2 The system shall be able to display alternative routes or modes at modal interchange points, or at places where tourism information is available.

6.2.1.3 The system shall be able to provide information about other transport modes: e.g. location of P+R areas, PT timetable, etc.

Re-produced by kind permission of Kent County Council, UK


© FRAME Team 9


The FRAME Selection Tool

© FRAME Team

Creating the Functional Viewpoint


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


Deployment Plan

System Boundary

Cost/Benefits

Risk Analysis

Component

Specifications

and

Communications

Requirements

Procurement Process

Relationship

Relationship

and

Feedback

© FRAME Team


Provides assistance to create

• A logically consistent sub-set of the FRAME Architecture (Functional Viewpoint)

• One, or more, Physical Viewpoints of that sub-set

• One, or more, Organisational Viewpoints of that sub-set

Available from the FRAME websitewww.frame-online.net


Using the Selection Tool



© FRAME Team 10

© FRAME Team

Recording the Selection of the User Needs


Selecting the Functions


• First Stage – primary Functions

• Subsequent Stages – supporting Functions

© FRAME Team

Selecting the Data Flows


• Select the Data Flows required for each Function to behave as required

© FRAME Team

Select the Data Stores


• Select the Data Stores that are required


© FRAME Team 11

© FRAME Team

Select Any Additional Data Flows


• Are any additional Data Flows required due to the (additional) Data Stores?

© FRAME Team

Select the Terminators/Actors


• Select the people/systems/etc . which get/provide data from/to this sub-set


Consistency Checking

There are two types of consistency checking


• Logical Consistency e.g.– Every Data Flow has an element at each end

• Function, Data Store, or Terminator/Actor

– Every Function has at least one input and one output– Does it make sense? – Maybe!

• Semantic Consistency– Logical consistency PLUS– All the correct elements are all being used in the correct way• Functions, Data Flows, Data Stores and Terminators/Actors

– Does it make sense? – Yes!

© FRAME Team

Check for Logical Correctness


• The process continues until no logical errors are reported


© FRAME Team 12

© FRAME Team

Creating a Physical Viewpoint


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


Deployment Plan

System Boundary

Cost/Benefits

Risk Analysis

Component

Specifications

and

Communications

Requirements

Procurement Process

Relationship

Relationship

and

Feedback

© FRAME Team

Define the Sub-systems


• The locations where groups of functions will reside

© FRAME Team

Allocation of Functions/Data Stores


• In which Sub-system does each Function and Data Store reside?

• Duplicate Functions, Data Stores and Data Flows can also be created

© FRAME Team

Define any Modules


• Is any Sub-system to be split into Modules?


© FRAME Team 13

© FRAME Team



• In which Module does each Function and Data Store reside?

© FRAME Team

Physical Data Flows


• The data that flows between each sub-system/module

• The details are also available in an Excel report


Sub-system

TerminatorTerminator

Physical Data Flow A

Constituent Physical Data Flows

• Some Physical Data Flows comprise other Physical Data Flows

Module 1

Module 2

Physical Data Flow 1


Physical Data Flow APhysical Data Flow 1



Using the Results


© FRAME Team 14


ITS Architecture Creation Process Products

Inter-operable Systems

Compare Solutions

Produce Specifications

Component

Specifications

Organisational

Issues

Risk

Analysis

Cost

Benefits

Deployment

Programme

Communications

Requirements

System

Boundary

ITS Architecture


© FRAME Team

Analysing a Physical Viewpoint


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


Deployment Plan

System Boundary

Cost/Benefits

Risk Analysis

Component

Specifications

and

Communications

Requirements

Procurement Process

Relationship

Relationship

and

Feedback


How to use the results

Organisational and Business Issues

Deployment Programme

Cost Benefits

Risk Analysis

System Boundary

Component Specifications

Communications RequirementsComponent Specifications


Risk Analysis

Cost

BenefitsDeployment Programme

Communications Requirements

System Boundary

ITS Architecture



What is a Component?

• An ITS service is provided by one or more Components

• A Component:

– Can be software, hardware and/or a combination

– Resides in a single physical location

• Several Components can reside in the same location

• A single supplier may provide:

– One or more of the Components needed for each ITS service

– One or more ITS services


© FRAME Team 15



• Must provide:

– Unambiguous descriptions

– List of Aspirations fulfilled

• Must be technology independent:

– State “what it will do”

– Do not state “how it will do it”

• Used by “purchasing organisation” in tender documents

– Can be split between several tenders

– Combined with other requirements, e.g. Terms & Conditions

© FRAME Team

Functional Descriptions


• From the Browsing Tool





Cost Benefits

Risk Analysis

System Boundary




Risk Analysis

Cost



System Boundary

ITS Architecture




• Produced for each link between Components and must support service delivery:– Must be readily available in the same way everywhere

– Long term commitment means technology independent interfaces

• Information about each link must include:– What: type of data, estimated size, etc.

– When: how often, latency

– Required Bandwidth: maximum expected

– Required Security and Other Constraints

– Link Type: wireless (what form) or wire-line

• Produced in table form for easy reference


© FRAME Team 16



Physical Data Flow

Constituent

Functional Data

Flows

Data

Type

Max Bytes /

Message

Max Delay

(seconds)

Message

Interval

(seconds)

Security

Level

Suggested

Transfer

Mode

mt_traffic_ommandsurban_lane_cmds Raw Data 100 0.5 15 None

Wire Lineurban_tfc_mgt_req Raw Data 100 1 5 None

Minimum Data Rate for Link 300 Bytes/Second None

Minimum Inter-Message Gap 5 Seconds

• Use European Communications Architecture to determine required standards and any technical constraints

• Resulting Communications Specifications used in “Calls for Tender”





Cost Benefits

Risk Analysis

System Boundary




Risk Analysis

Cost



System Boundary

ITS Architecture



Sources of Organisational Issues

• Who owns, operates, regulates and maintains:– Each component?

– Each communications link?

• What is the financial set up:– Who is paying for ITS implementation?

– Is there a revenue stream and if so:• Who collects it?

• Who gets it?

• What happens to data in the System:– Who collects it?

– Who processes it?

– To whom is it made available?

– Are there privacy issues for any of these?


Analyse Involvement of Organisations with Components

• For each component and communication link identify its:– Owner

– Operator

– Regulator

– Maintainer

• Characterise links between organisations:– Number of organisations involved

– Potential for difficult relationships

• Take action to resolve issues, e.g.:– Change the “culture”

– Produce contractual relationships

– Revise components


© FRAME Team 17

© FRAME Team

Creating an Organisational Viewpoint


Stakeholder

Aspirations

User Needs

Functional

Viewpoint

FRAME

Architecture

Communications

Viewpoint

Physical

Viewpoint

Relationship

Relationship

Relationship

Relationship

and

Feedback


Consultations


Deployment Plan

System Boundary

Cost/Benefits

Risk Analysis

Component

Specifications

and

Communications

Requirements

Procurement Process

Relationship

Relationship

and

Feedback

© FRAME Team

Define the Organisations


• The (types of) organisations that will ownand/or manage and/or operate the functions

© FRAME Team



• Which organisation is responsible for each Function and Data Store?

• Duplicate Functions, Data Store and Data Flows can also be created

© FRAME Team

Organisational Data Flows


• The data that flows between each organisation

• The details are also available in an Excel report


© FRAME Team 18


Summary

© FRAME Team

What does the FRAME Architecture provide?

• Two tools:

– FRAME Browsing Tool: enables the Architecture contents to be studied in detail

– FRAME Selection Tool: enables the creation of sub-sets of the Architecture for particular ITS implementations

• Both tools freely available from FRAME website at: www.frame-online.net

• Support for their use is available via the website [email protected] facility



Using the FRAME Tools to create an ITS Architecture

Component

Specifications


Risk Analysis

Cost Benefits



System

Boundary

ITS Architecture


Stakeholder Realisations

FRAME Selection Tool

CommunicationsRequirements



System Boundary


Cost Benefits

Risk Analysis

FRAME Architecture

Stakeholder Realisations


FRAME Browsing Tool

= Optional


If you want to know more?

• FRAME Forum has taken over some of the activities of the E-FRAME project

• It can provide the following:

– FRAME Seminar: a short high level introduction to ITS Architecture aimed at high-level decision makers

– FRAME Workshop: 1-2 day instruction on how to use the European ITS Framework (FRAME) Architecture

– Help and advice: covers the creation and use of ITS architectures

• Further information, contact details and a lot more can be found on the FRAME website at:

www.frame-online.net

actif workshop - how - 02

Documents