actif workshop - how - 02
Post on 19-Jul-2016
240 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
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
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
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
ACTIF Team Presentation, Paris – September 2012 24
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
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
The FRAME Architecture - "How"
© FRAME Team 7
© FRAME Team
Stakeholder Aspirations
ACTIF Team Presentation, Paris – September 2012 25
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 ACTIF Team Presentation, Paris – September 2012 26
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
© FRAME Team ACTIF Team Presentation, Paris – September 2012 27
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
© FRAME Team ACTIF Team Presentation, Paris – September 2012 28
Stakeholder Aspirations
• 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
The FRAME Architecture - "How"
© FRAME Team 8
© FRAME Team ACTIF Team Presentation, Paris – September 2012 29
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
ACTIF Team Presentation, Paris – September 2012 30
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
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
The FRAME Architecture - "How"
© FRAME Team 9
© FRAME Team ACTIF Team Presentation, Paris – September 2012 33
The FRAME Selection Tool
© FRAME Team
Creating the Functional Viewpoint
ACTIF Team Presentation, Paris – September 2012 34
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
The FRAME Selection Tool
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
ACTIF Team Presentation, Paris – September 2012 35 © FRAME Team
Using the Selection Tool
ACTIF Team Presentation, Paris – September 2012 36
The FRAME Architecture - "How"
© FRAME Team 10
© FRAME Team
Recording the Selection of the User Needs
ACTIF Team Presentation, Paris – September 2012 37 © FRAME Team
Selecting the Functions
ACTIF Team Presentation, Paris – September 2012 38
• First Stage – primary Functions
• Subsequent Stages – supporting Functions
© FRAME Team
Selecting the Data Flows
ACTIF Team Presentation, Paris – September 2012 39
• Select the Data Flows required for each Function to behave as required
© FRAME Team
Select the Data Stores
ACTIF Team Presentation, Paris – September 2012 40
• Select the Data Stores that are required
The FRAME Architecture - "How"
© FRAME Team 11
© FRAME Team
Select Any Additional Data Flows
ACTIF Team Presentation, Paris – September 2012 41
• Are any additional Data Flows required due to the (additional) Data Stores?
© FRAME Team
Select the Terminators/Actors
ACTIF Team Presentation, Paris – September 2012 42
• Select the people/systems/etc . which get/provide data from/to this sub-set
© FRAME Team ACTIF Team Presentation, Paris – September 2012 43
Consistency Checking
There are two types of consistency checking
The FRAME Selection Tool
• 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
ACTIF Team Presentation, Paris – September 2012 44
• The process continues until no logical errors are reported
The FRAME Architecture - "How"
© FRAME Team 12
© FRAME Team
Creating a Physical Viewpoint
ACTIF Team Presentation, Paris – September 2012 45
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
Define the Sub-systems
ACTIF Team Presentation, Paris – September 2012 46
• The locations where groups of functions will reside
© FRAME Team
Allocation of Functions/Data Stores
ACTIF Team Presentation, Paris – September 2012 47
• 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
ACTIF Team Presentation, Paris – September 2012 48
• Is any Sub-system to be split into Modules?
The FRAME Architecture - "How"
© FRAME Team 13
© FRAME Team
Allocation of Functions/Data Stores
ACTIF Team Presentation, Paris – September 2012 49
• In which Module does each Function and Data Store reside?
© FRAME Team
Physical Data Flows
ACTIF Team Presentation, Paris – September 2012 50
• The data that flows between each sub-system/module
• The details are also available in an Excel report
© FRAME Team ACTIF Team Presentation, Paris – September 2012 51
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 2
Physical Data Flow APhysical Data Flow 1
Physical Data Flow 2
© FRAME Team ACTIF Team Presentation, Paris – September 2012 52
Using the Results
The FRAME Architecture - "How"
© FRAME Team 14
© FRAME Team ACTIF Team Presentation, Paris – September 2012 53
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
Stakeholder Aspirations
© FRAME Team
Analysing a Physical Viewpoint
ACTIF Team Presentation, Paris – September 2012 54
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 ACTIF Team Presentation, Paris – September 2012 55
How to use the results
Organisational and Business Issues
Deployment Programme
Cost Benefits
Risk Analysis
System Boundary
Component Specifications
Communications RequirementsComponent Specifications
Organisational Issues
Risk Analysis
Cost
BenefitsDeployment Programme
Communications Requirements
System Boundary
ITS Architecture
Stakeholder Aspirations
© FRAME Team ACTIF Team Presentation, Paris – September 2012 56
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
The FRAME Architecture - "How"
© FRAME Team 15
© FRAME Team ACTIF Team Presentation, Paris – September 2012 57
Component Specifications
• 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
ACTIF Team Presentation, Paris – September 2012 58
• From the Browsing Tool
© FRAME Team ACTIF Team Presentation, Paris – September 2012 59
How to use the results
Organisational and Business Issues
Deployment Programme
Cost Benefits
Risk Analysis
System Boundary
Component Specifications
Communications RequirementsComponent Specifications
Organisational Issues
Risk Analysis
Cost
BenefitsDeployment Programme
Communications Requirements
System Boundary
ITS Architecture
Stakeholder Aspirations
© FRAME Team ACTIF Team Presentation, Paris – September 2012 60
Communications Requirements
• 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
The FRAME Architecture - "How"
© FRAME Team 16
© FRAME Team ACTIF Team Presentation, Paris – September 2012 61
Communications Requirements
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”
© FRAME Team ACTIF Team Presentation, Paris – September 2012 62
How to use the results
Organisational and Business Issues
Deployment Programme
Cost Benefits
Risk Analysis
System Boundary
Component Specifications
Communications RequirementsComponent Specifications
Organisational Issues
Risk Analysis
Cost
BenefitsDeployment Programme
Communications Requirements
System Boundary
ITS Architecture
Stakeholder Aspirations
© FRAME Team ACTIF Team Presentation, Paris – September 2012 63
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?
© FRAME Team ACTIF Team Presentation, Paris – September 2012 64
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
The FRAME Architecture - "How"
© FRAME Team 17
© FRAME Team
Creating an Organisational Viewpoint
ACTIF Team Presentation, Paris – September 2012 65
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
Define the Organisations
ACTIF Team Presentation, Paris – September 2012 66
• The (types of) organisations that will ownand/or manage and/or operate the functions
© FRAME Team
Allocation of Functions/Data Stores
ACTIF Team Presentation, Paris – September 2012 67
• 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
ACTIF Team Presentation, Paris – September 2012 68
• The data that flows between each organisation
• The details are also available in an Excel report
The FRAME Architecture - "How"
© FRAME Team 18
© FRAME Team ACTIF Team Presentation, Paris – September 2012 69
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 info@frame-online.net facility
ACTIF Team Presentation, Paris – September 2012 70
© FRAME Team ACTIF Team Presentation, Paris – September 2012 71
Using the FRAME Tools to create an ITS Architecture
Component
Specifications
Organisational Issues
Risk Analysis
Cost Benefits
Deployment Programme
Communications Requirements
System
Boundary
ITS Architecture
Stakeholder Aspirations
Stakeholder Realisations
FRAME Selection Tool
CommunicationsRequirements
Component Specifications
Organisational Issues
System Boundary
Deployment Programme
Cost Benefits
Risk Analysis
FRAME Architecture
Stakeholder Realisations
Stakeholder Aspirations
FRAME Browsing Tool
= Optional
© FRAME Team ACTIF Team Presentation, Paris – September 2012 72
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
The FRAME Architecture - "How"
© FRAME Team 19
© FRAME Team ACTIF Team Presentation, Paris – September 2012 73
Thank you for listening
top related