Gliederung des Dokuments - oca-ev.info · the so called OTS-initiative (Open traffic systems...

© OCA – Open Traffic Systems City Association

OTS-Guideline, /66

Summary abstract

The renewal or extension of an existing traffic control or traffic management system or its upgrade to a local, regional or national ITS-system are tasks that may vary to a great extend in each individual case. Persons who are responsible for such a task have to develop a solution concept which takes "all" requirements associated to the solution into account. The solution concept must be detailed and refined insofar that the parts of the solution can be clearly identified and specified in a fashion that in the end they can be tendered and procured according to the regulations of public procurement law.

The OTS-Guideline addresses people in public administrations in their role as contracting body who are involved in different ways and with different powers, skills and responsibilities in the design, planning and implementation of the renewal or extension of existing systems in the transport sector.

The OTS-Guideline accompanies the entire process of conception and procurement and provides a plausible step by step approach. The main focus is laid on the conceptual design process which serves as the basis for the "input" and realisation of the procurement. The mapping of conceptual (partial) solutions to specification documents is a task where the correct transfer of concepts into a verifiable specification is crucial. Whatever is misinterpreted or omitted at this stage can hardly be corrected at a later stage.

The OTS-Guideline therefore provides answers to the following questions, which in practice often come up again:

How to proceed - under the constraint of public procurement – with system modernisation or system redesign and procurement of a complex system in the traffic environment?

How to deal with a vendor mixed environment as a way of flexible adaptation without the associated negative effects?

How to do the technical specification for a tender in terms of OTS, without violating the public procurement law; what lots are useful?

From OCA’s perspective and with regard to its step by step approach the OTS-Guideline extends the POSSE Good Practice Guidelines in a detailed way. And although OTS is also a publicly available ITS standard, the OTS-Guideline can be used independent from the ITS standard preferred.


OTS-Guideline, /66

Document Structure

This document is structured in five parts as follows:

PART I INTRODUCTION

The introduction explains the central importance of the OTS-Guideline. The reader gets to know its objectives and motivation as well as the scope and the underlying concept.

PART II WORK CONCEPTS

Part II introduces work concepts, with which the user should deal with in order to use the OTS-Guideline in an efficient and profitable way.

Furthermore, aspects of the system’s design and architecture are analysed and it is illustrated, which basic knowledge is required for Part III.

PART III PRAXIS

The praxis part shows the actual process from system design to application.

PART IV OUTLOOK

Part IV states and reasons the necessity of special qualification for future users of the OTS-Guideline.


OTS-Guideline, /66

Table of content

PART I INTRODUCTION 5

1. History 5

2. Objectives of this guide and who is it for 6

3. Purpose of this guide 7

4. Vendor mixed environment as a challenge 8

PART II WORK CONCEPTS 10

5. The introduction to the application of the OTS-Guideline 10

5.1 The starter pack of basic knowledge ........................................................................ 10

5.1.1 Concepts and cooperation .................................................................................................................. 10 5.1.2 General concept for structuring a system ......................................................................................... 10 5.1.3 Subsystem as methodological element ............................................................................................. 10 5.1.4 System specification and lots............................................................................................................. 11 5.1.5 System identification ........................................................................................................................... 11 5.1.6 Subsystem realisation and a vendor mixed environment ............................................................... 12 5.1.7 Subsystem specification ..................................................................................................................... 13

5.2 Organisation of the process ....................................................................................... 14

5.2.1 OCA’s approach as methodological resource .................................................................................. 14

PART III PRAXIS 17

6. Process of system design and implementation 17

6.1 Sequence 1: Problem Classification ......................................................................... 17

6.2 Sequence 2: System Identification ............................................................................ 24 6.3 Sequence 3: Requirement Specification (Contract Specification) .......................... 33 6.4 Sequence 4: Tendering ............................................................................................... 48 6.5 Sequence 5: Tender Evaluation and Comparison .................................................... 51 6.6 Sequence 6: Solution Specification (Performance Specification) .......................... 56

6.7 Sequence 7: Field Test ............................................................................................... 58 6.8 Sequence 8: Trial Operation ....................................................................................... 63

PART IV OUTLOOK 65

7. Qualification and quality 65


OTS-Guideline, /66

PART I INTRODUCTION

1. History

Local Authorities in the DACH area (Germany, Austria and Swiss) were already under pressure in the early nineties to bring down costs for traffic signal systems procurement by opening up the traffic controller market to competition. As an appropriate tool the use of interface / communication standards were considered thus breaking up so called monolithic silo-systems into several parts, which then could be tendered and procured separately as different procurement lots. As no one single interface standard was available on the market at that time the initial reaction of persons responsible for public procurement was to establish and to stipulate individual interface standards for each local authority separately.

As this would have incurred incalculable risks in terms of costs for interface development and maintenance a group of five German system suppliers initiated the so called OCIT®-initiative in 1999 (OCIT® stands for Open Communication Interface for Traffic Systems, see www.ocit.org), which aimed at replacing specific local authority standards with a single, open industry standard, named OCIT®.

As reaction on this industrial effort a group of local authorities initially of ten bigger cities founded an association named OCA (Open Traffic System City Association e.V., see www.OCA-eV.org) to determine their interests and to play a role alongside industry in the upcoming standardisation process. Today the OCA has grown up to an international association of about 40 German, Austrian and Swiss public road authorities. The majority of OCA’s members represent metropolitan areas and cities; some are regional bodies and city associations themselves.

The purpose of the OCA, membership of which is open to any municipality and all other public road authorities, is on the one hand to encourage competition between suppliers through the creation and application of standards and open interfaces between ITS-systems and components and on the other hand to improve the efficiency and quality of procurement and operation. These goals are also reflected in the articles of the German law-registered association. OCA’s members commit to:

improve efficiency through open interfaces and technologies and

create more competition in the procurement and operation of systems

simplify the tendering procedure

encourage the direct exchange of information between municipalities on a national and international level

consolidate user needs and requirements to be in a stronger position vis-à-vis industry

Going beyond: the OTS-initiative

Despite the broad acceptance in greater parts of middle Europe and despite its financial success for the user side OCIT® shows also some weaknesses. On one hand they result from the resistance of the industry side to fulfil important user requirements. On the other hand they are based on the fact, that the OCIT® initiative targeted exclusively the domain of traffic signal control and that the OCIT®- communication standard is not designed to respond to requirements that go beyond those first and most economically motivated aspects of facilitating vendor mixed traffic light systems.

Such requirements result from projects, which have the political claim for sustained improvement of traffic conditions by the mean of an integrated network management. As a consequence of that, traffic light control systems are requested to be extended beyond their original purpose in order to be part of greater traffic management approaches e.g. re-routing in overloaded urban/inter-urban networks or in order to support entirely new services like e.g. contributing to traffic situation analysis and reports by delivering traffic online data. Such

http://www.ocit.org/

http://www.oca-ev.org/

http://dict.leo.org/ende?lp=ende&p=DOKJAA&search=articles&trestr=0x8001


OTS-Guideline, /66

objectives can only be reached if conventional traffic control systems are integrated into so called “traffic management- and traffic telematics systems.

The renewal or extension of an existing traffic control or traffic management system or its upgrade to a local, regional or national ITS-system are tasks that may vary to a great extend in each individual case. Persons who are responsible for such a task have to develop a solution concept which takes "all" requirements associated to the solution into account. The solution concept must be detailed and refined insofar that the parts of the solution can be clearly identified and specified in a fashion that in the end they can be tendered and procured according to the regulations of public procurement law.

In addition to the specification of features which aim to fulfil traffic and transportation requirements the issue of a creating a vendor mixed environment by the specification of appropriate interoperability features is of increasing importance. In a world, where far going user expectations cannot be met anymore by a single system but only by the establishment of greater networks of systems and where the creation of added value in terms of the ITS-directive needs cross-organizational interworking, it must be ensured that subsystems or components, which may be supplied by different vendors, interoperate not only among themselves but also with an existing system environment in the correct way.

To support persons, which are in charge to renew or extend their existing systems and by this occasion intend to start a vendor mixed environment strategy the OCA started in 2004 the so called OTS-initiative (Open traffic systems initiative) and in succession has developed the OTS-Guideline.

2. Objectives of this guide and who is it for

Objective and purpose of the OTS-Guideline is to accompany the entire process of conception and procurement in the sense of OTS – Open traffic systems. The main focus is laid on the conceptual design process which serves as the basis for the "input" and realisation of the procurement. The mapping of conceptual (partial) solutions to specific documents (so called quality documents, Q-artefacts) of the OCA-procurement process model (OCA approach) is a task where the correct transfer of concepts into a verifiable specification is crucial. Whatever is misinterpreted or omitted at this stage can hardly be corrected at a later stage.

The OTS guide handles the conception basically as a modernisation or redesign of systems. A role which is typically associated with such a task is that of system architects. The solution concept can therefore be seen as a mean of system architecture.

Barrier-free or untroubled system aggregation of subsystems of different vendors to a system is considered as such a requirement. For the interpretation of this standard the concept of "distributed systems" is taken. This means a system solution should comprise the characteristics of a "distributed system" independent of whether it is a mixed vendor implementation or from the same manufacturer. The feature to be emphasized is the loose link-up of subsystems in a subsystem network, which means that exchange of information and thus communication is an essential part of the specification.

The OTS-Guideline therefore provides answers to the following questions, which in practice often come up again:

How to proceed - under the constraint of public procurement – with system modernisation / system redesign and procurement of a complex system in the traffic environment?

How to deal with a vendor mixed environment as a way of flexible adaptation without the associated negative effects?

How to do the technical specification for a tender in terms of OTS, without violating the public procurement law; what lots are useful?

The OTS-Guideline addresses people in public administrations in their role as contracting body who are involved in different ways and with different powers, skills and responsibilities


OTS-Guideline, /66

in the design, planning and implementation of the renewal or extension of existing systems in the transport sector. But it also addresses people,

who are entrusted with the implementation of certain interests of entities or

who are contractor with the wish to satisfy the customers’ desires, and therefore need to better understand what is meant by terms of Q-artefacts from the customers point of view.

3. Purpose of this guide

The OTS-Guideline represents a value in itself, because the knowledge about composite systems in the field of traffic management and ITS compiled in the OTS instruments (OTS-System model, OTS-procurement process model and OTS-application guidance) does not exist in this form in any other document available.

With the application of the OTS guide general OCA goals are realised in course of time. In concrete terms, this means:

Standardization and facilitation of the procurement process, starting from system specification through to testing and acceptance, especially if the contract award is bound to the public procurement law.

Standardization of the system specification (in terms of structure and used terminology) with support for consensus-building between client and contractor, especially when the specification documents are subject to public tender.

Facilitation of the implementation of a vendor mixed environment through the use of open standards for communication interfaces (e.g. OCIT® / OTS). This results in:

lower prices through increased competition,

a wider range of potential suppliers,

the ability to use the most powerful subsystem at any position in the chain.

Support for the OTS process which was introduced and moderated by the OCA.

Provision of models (OCA approach, OTS-system model), which serve as a guide to the users of the OTS-Guideline.

In addition, users of the OTS-application guidance can access examples of specific realisations via the reference list and profit from them. The user can understand and possibly transfer the goals and their achievements documented in the examples to his own needs.

In particular the following benefits can be expected by different parties:

Benefit for the contracting body (authorities, operators and system architect): The authorities and operators use the OTS-concept for all phases of action as justification in procurement processes, i.e. in problem classification, system identification, the requirements specification (tender document), the evaluation of bids (and the comparison of bids), the solution specification (requirements specification), the field test, the test operation and the acceptance test. The OTS concept provides to the persons entrusted with the task of system design basic knowledge and competence based on different models (OCIT® Instations and OTS-system model, OCA approach, other meta models such as ISO / OSI reference model) in order to structure safely perform a system design process.

Use for the contractor supplier (manufacturer): The manufacturer uses the OTS-concept for proposal preparation, solution specification (requirements specification), field testing and trial operation. In addition, the benefit for the contractor / vendor lies in the homogeneity and accuracy of specifications in the public procurement process or tenders and how to deal with it.


OTS-Guideline, /66

Use for further interest groups: The benefit of the OTS concept for further interest groups needs to be considered with respect to the OTS framework. Interest groups can synchronize their position with that of the OCA if desired.

The use of OTS-Guideline in its current form requires an unspecified form of knowledge. The issues described at the conceptual level of the procedure show the limits of understanding. Anyone who cannot map the represented information on personal experience or background knowledge has comprehension deficits. This needs to be sorted out by each user himself.

The OTS-Guideline also requires the existence of a communication standard like OCIT or OTS1/2. OCIT or OTS may not be available or suitable to countries outside of the DACH-Market. Nevertheless, the general considerations for distributed systems are independent and still applicable, although not 1:1. Interrelationships of subsystems may need to be implemented via other standards.

4. Vendor mixed environment as a challenge

A vendor mixed environment results out of the demand for and the introduction of competition. This requirement leads to a split of the tender into various lots, to achieve the best price / performance ratio. The separate lots must be specified in a way to enable potential suppliers to offer a solution, even if the lot has a functional dependence on other lots or to existing systems.

By extending an existing system with systems from different vendors, like a traffic management or ITS system for instance or integration of other system components from other manufacturers, the complexity of the system environment increases.

However, the mix of systems of different manufacturers is also a result from technological change. Established companies are suddenly in competition with new companies that exploit technological changes for their market access to offer exclusively or at a reasonable price new or improved functionalities for sub systems in the context of renewal cycles.

Figure 1: Typical demands leading to vendor mixed environments

A vendor mixed environment is not a goal but a (usually troublesome) way to adapt local system structures to the current local and strategic during the course of renovation or alteration. This means existing systems of one manufacturer, which have due to various, mostly historical reasons very different functional and technological characteristics, need to be distributed appropriately and combined with new parts according to local circumstances and opportunities. Interoperability and data exchange, which so far took place in manufacturer monolithic systems almost like in a black box, must now be realised via open interfaces. Only where such interfaces can be implemented using existing standards and existing implementations of such standards, the realisation of systems of different manufacturers is possible with manageable effort.

The challenge is also to integrate existing systems - often from different manufacturers - with new systems - often from other manufacturers - into a composite system. Systems must be specified to form independent lots for sub system and their services as parts of the tender so that as a result various manufacturers may calculate, offer and deliver their products without any “problems”. Problems often arise from inadequate lots specifications. This creates the risk of procurement complaints or a difficult consensus building with delays and further supplementary claims by suppliers.


OTS-Guideline, /66

Not only parts from different manufacturers, but also parts of a network being spread over various jurisdictional borders (public and private) and following different objectives (system philosophy, framework for the operation, etc.) may lead to problems in the specification and the integration process.

The benefits of open specifications and standards are clear, but they require effort to draft, review, implement, revise, deploy and use. Furthermore, because they are open, they require a lot of different organizations to play their part. The goal is a standards “ecosystem” which is of benefit to everyone – without entailing unreasonable cost or risk to each organisation.


OTS-Guideline, /66

PART II WORK CONCEPTS

5. The introduction to the application of the OTS-Guideline

5.1 The starter pack of basic knowledge

5.1.1 Concepts and cooperation

The OTS-Guideline provides primarily concepts that serve as a basis to develop a common understanding of reality on system architecture and methodological approach on a high level of abstraction. The OTS-Guideline shows ways to deal with these concepts.

The starter pack of basic knowledge discusses general concepts. They mainly serve the consensus-building. The concepts describe a basic set of terminology (knowledge) with which an entry can be made in the interpretation of the design task.

5.1.2 General concept for structuring a system

The concepts of system, subsystem and a distributed system have been discussed earlier. In summary, the following can be said:

Each system is a subsystem, can as such be interpreted as a part of an overall system and may also contain subsystems. Subsystems exchange messages with other subsystems and need means of communication.

In the course of analyses it must be identified, which subsystems represent the existing reality and which subsystems should be the subject of procurement.

If a service is provided through a network of subsystems, each subsystem requires certain behaviour from other subsystems whose successful input is the condition to realise the initiated behaviour. If all the subsystems are specified, it must be checked at the end of iteration for each subsystem which requirements of other sub-systems it has to fulfil. For subsystems that are already existing it is necessary to determine whether they meet the demands.

This process is outlined in the following figure:

Figure 2: Example of a system structure to be specified

5.1.3 Subsystem as methodological element

The term subsystem extends the understanding of the term system. The idea that subsystems in turn can contain subsystems is called packaging or composition. A model element which represents a system and is characterised as subsystem, shall have the fundamental property of being made up ofsubsystems. This creates the possibility of a hierarchical composition of a system. By the principle of any system being modelled as a subsystem it may therefore be as well part of a parent, perhaps not yet existing, subsystem.

System

system case (system) gets tangible only due the specifications of the subsystems

Teilsystem

subsystem

subsystem

requirements(for the system performances of the subsystems)

requirements(to communicative

behaviour within special context)

subsystem of interest

requirements(for the system performances of the subsystems)

requirements(to communicative

behaviour within special context)

subsystem of interest


OTS-Guideline, /66

With this the term subsystem does not only bear the meaning of the term system, but provides for a basic structuring of a system into subsystems as well, which by the way needs to be done while defining the lots, too.

If several subsystems are assigned to one lot as a package then it must still be decided on whether the "internal" communication should be the subject of the specification or not.

5.1.4 System specification and lots

A procurement action that is part of a public procurement procedure needs to be compliant to rules and conditions. These are assumed to be known. The requirements specification (tender document) plays an important role in such processes. It describes all items of delivery and services to be supplied. These are usually hardware to deliver, software to be developed and services to be done.

Market-related reasons, scheduling or other reasons may be reason to divide the specification into parts and procure each of these as a separate lot, or even in separate tender. The granularity of the division is made according to criteria which are in the responsibility of the organisation only which issued the invitation to tender.

For a distribution is should be noted that it is required by implication, that all products and services of different manufacturers must be able to be joined together or combined so that the overall performance meets the expectations of the initiator and is really testable by that means. For successfully merging and testing the subsystems it may therefore be necessary to issue a separate service, e.g. to tender system integration.

5.1.5 System identification

Often one is confronted with the situation that the system to specify replaces, expands or modifies (see also Scenario 1) an existing system. In any case, it is necessary to identify the system so that all stakeholders involved understand how it does relate to the existing system and its environment.

This is usually done through the description of the interaction of the system, which is to be specified, with the environment.

As part of system identification concepts about a distribution of the system into subsystems will or may be developed. If the idea of dividing the tender into several lots is already present, it must consequently be noted that the system originally identified may not have to be regarded in form of a whole realisation. The combination of the subsystems will result in the realisation of the system. Thus, the communicative relations of the system originally identified need to be mapped onto the communicative relationships among the subsystems, and the subsystems with the system environment. One example is a traffic management system which is constructed in accordance with the OTS-system model which was developed in Dmotion.


OTS-Guideline, /66

Figure 3: OTS-system model

5.1.6 Subsystem realisation and a vendor mixed environment

The scope of the specification of a subsystem is determined also by the desired form of implementations of the subsystems or by the conditions the realisation is bound to. For the handling of the topic it is helpful to specify points in time up to which analyses are carried out isolated from the realisation. It is also important to know how the term subsystem is to be associated with forms of implementations.

Each implementation of a subsystem results in either

one component or a composition of components that work together with other components in form of interaction points (IP) and can exchange data or

a node (IT system, computer) or an aggregation of nodes that are interconnected or

a mixture of the above combining the previous two bullet points.

Applications implement a specified functionality from the user perspective. They use services of the respective execution environment to provide their service and to realise their communication with other applications (programming, operating systems, and hardware).

A mix of manufacturers is supported to the extent of how manufacturers of components and nodes agree on the use of communications standards that are compatible and available for different runtime environments. As standards are expected to have a long-term validity, there is the additional problem to incorporate highly re-usable services in these standards, regardless of the application-specific functionality.

Each realisation usually implies that the corresponding delivery is integrated into an existing system landscape. The behaviour of a realisation with respect to its environment, i.e. the interaction, needs to be tested to see whether it matches the specified behaviour. This is called compliance test. A vendor mixed environment becomes a problem if a compliance test is not objectively possible. That is, if it cannot be verified by a third party how applications of

Traffic Management

(Urban) Road Operator Other

Road

Operator

Service ProviderT

raff

ic M

an

ag

em

en

t L

ev

el

Ce

ntr

al L

ev

el

Fie

ld

Le

ve

l

Traffic

Information

Services

Mo

bilit

y

Se

rvic

es

Na

vig

ati

on

s

Se

rvic

es

Co

nte

nt

Ce

nte

r

FCD

Service

OCIT®-Instations/OTS

OCIT®-Outstations

No Standard

Traffic Data Collection Traffic Control Traffic Directing

RRC PLTSIL

Traffic Control

Centre

IL IR Video

Traffic Detection

Centre

Elec.

BarriersVMS

PGS

P&RFCD FCD

Strategy

Management

Traffic Models

Inte

r-u

rba

n T

raff

ic M

an

ag

em

en

t (e

.g. m

oto

rwa

ys

)

Ta

xi C

on

tro

l

Ce

ntr

e

Route Guidance

Centre

Content Centre

Traffic DataBetriebsmelde-

System

Logging

System

OTS-Systemmodell, © OCA e.V. 11/2009

IL Induction Loop

IR Infra-red

RRC Rail Road Crossing

TS Traffic Signal

PL Permanent Light

PGS Parking Guidance System


OTS-Guideline, /66

delivered nodes communicate with applications of other nodes in order to provide the specified services.

Note: An implementation on an isolated node or as an isolated node has no communicative relationships with other nodes. Nevertheless, there may also run communication processes within a node.

5.1.7 Subsystem specification

A subsystem specification is a description of a subsystem, which has to be developed and/or delivered by a vendor based on this description. Of course, the delivery should comply demonstrable with all requirements of the specification. There is in general a risk that the deliverable does not meet the desired system. Reasons may be:

The system is not described accurately enough: this means that the manufacturer may add missing semantics from its own perspective.

The system is described incompletely: this means that the manufacturer may fill gaps as of his own interpretation

As always with any specification there is the risk that something is specified too vague or with gaps. Therefore a mechanism should be implemented in the procurement process to minimize the risks associated with inadequate specification.


OTS-Guideline, /66

5.2 Organisation of the process

5.2.1 OCA’s approach as methodological resource

Part III Praxis below describes the actual process from system design to implementation. A OCA approach was developed to accommodate the creative degrees of freedom, necessary for the design, to the constraints of acquisition compliant to the public procurement law.

The approach interprets the concepts of the well-known process models RUP (rational unified process) and V-model XT and transfers them to the client’s process from requirement specification to final acceptance. In contrast to the V-model XT it takes no influence on the agent’s process and blanks it out.

The following picture illustrates the client’s process. It shows the way beginning with a problem without a concrete solution (black-box-view) to a fully developed and accepted system (white-box-view). Additionally disciplines, main actors/participants, milestones and OCA approach templates (quality artefact) all connected to the process are pictured.

Documents

without Sp.SSSS

Quality-

Artefacts

Solution Specification

Q-Artefacts

Participants

Main Actor

Milestones

Sequences

Disciplines

SO/IS, SSS, IM, G, SD SO/IS, SSS, G

CL Provider R/AN

CL

CL

Provider

CON

CL

jProblem Classification,

kSystem Identification,

lRequirement Speci-

fication (Contract Sp.)

mTenderingnTender

Evaluation & Comparison

oSolution Specification

(Performance Specification)

WRealisationqTrial

OperationpField Test

Concept,

Implementation

& Test

Integration & Evaluation

Start Publication Submission Allocation Start of

ImplementationInitiation

Readiness for

Acceptance Acceptance

Black-Box View White-Box View

Specifying Quality Artefacts: System Overview and Interface Specification (SO/

IS)

Subsystem Specifikation (SSS)

Consensus Building Quality Artefacts: Conformity Matrix (CM)

Supporting Quality Artefacts: Interaction Matrix (IM)

Glossary (G)

Stakeholder Document (SD)

Black Text Red Text

Colour Legend: O-Model-Process

Realiser-Process

Client (CL)

Contractor (CON)

CL & CON

Problem Analysis/

Requirement

Specifikation

CM

Requirement Analysis

Figure4: disciplines, sequences, milestones and Q-artefacts of the OCA-process model

In detail the OCA approach differentiates between the eight following sequences:

1. Problem classification

2. System identification

3. Requirement specification (contract specification)

4. Tendering

5. Tender evaluation and comparison

6. Solution specification (performance specification)


OTS-Guideline, /66

7. Field test

8. Trial operation

The sequence “realisation“ is part of the realizer-process and is not restricted by the OCA approach.

Parallel to all sequences templates are given. They are called quality artefact, for short Q-artefact. An overview of these templates is shown in the following figure:

Figure5: categorisation of the Q-artefact fielded in service description and specification

Passing through the different sequences, the Q-artefacts are dealt with. There are three types of artefacts:

Specified documents

Establishing documents

Supporting documents

The first category includes the documents system overview and interface specification (SO/IS) and subsystem specification (SSS). The document SO/IS describes the conceptual system understanding regarding its construction and defines interfaces between the various subsystems. For every complete system a document is created. The SSS specifies a subsystem as part of a system solution. In this case a document is created for every subsystem.

The conformity matrix (CM) is an establishing document and opposes the customer requirements to the functionality of a subsystem. With this matrix it is possible to survey the requested functionality of the specified solution even with several subsystems. Thus it is ensured that no functionality will be forgotten. Again one document for every subsystem is created.

Furthermore it is differentiated between three supporting documents. The interaction matrix (IM) describes the communicative relations of all subsystems. The stakeholder document (SD) includes all persons resp. their roles participating in the system and shows their interests. The glossary (G) clarifies technical terms and abbreviations. Those three documents are created once per complete system and contribute to the better understanding of the other documents.

Service Description

Interaction Matrix (IM)(1 document per overall system)

Subsystem Specification (SSS)(1-document solution , 1 document per subsystem)

Glossary (G)(1 document per overall system)

Stakeholder Document (SD)(1 document per overall system)

System Overview and Interface Specification (SO/IS)

(1-document solution , 1 document per overall system)

Service Specification

Conformity Matrix (CM)(1 document per overall system)

Service Specification(1 document per overall system)


OTS-Guideline, /66

The client is still free to create the service description on the basis of their own templates (e.g. MS Excel, ARRIBA etc.).

Figure6: Overview on the sequences of the praxis part

Sequence 3: Requirement Specification (Contract Specification)¤ Precise Vision of the System

P Publication of the Completed Subsystem Specifications

. SO/IS . SSS

. SD . G

Sequence 4: Tendering¤ Published Tender Documents

P Submission

. SO/IS . SSS . G

Sequence 2: System Identification¤ Vision of Solution

P Precise Vision of the System

. SO/IS . IM

Sequence 1: Problem Classification¤ Urgency to Act

P Vision of Solution

. SO/IS

Sequence 7: Field Test¤ Realised and Supplied System

P Readiness for Acceptance

Sequence 6: Solution Specification (Performance Specification)¤ Granted Award

P Realisation Parameters

. CM

Sequence 8: Trial Operation¤ Acceptance

P Accepted System

Sequence 5: Tender Evaluation and Comparison¤ Tenders of the Providers

P Placing / Award of Contracts

Symbols: ¤ Initial Situation P Target . Template


OTS-Guideline, /66

6. Process of system design and implementation

6.1 Sequence 1: Problem Classification

In order to be able to develop a problem-solving vision, the problem must be clarified first. Starting position for sequence 1 – problem classification is urgency; the goal which should be achieved is a vision of solution. An overview of sequence 1 and the thereby connected activities is given by the following figure.

Figure7: Process of the system design and implementation, activities sequence 1

But, before starting with the activity “qualification step”, the following is necessary to understand.

To let others know about one’s thoughts and desires or to communicate about targets, which have to be realised, a distinct and non-ambiguous language is obligatory.

Qualification Step:

Creation of terms to

classify problems

Vision of SolutionP

Vision of Solution:

Description of the

problem, the vision of

solution (i.a. alternatives)

and the associated value

proposition

Problem Evaluation:

Classification of one’s

problem with scenarios

Sequence 1: Problem Classification¤ Urgency to Act

P Vision of Solution

. Template SO/IS

PART III PRAXIS


OTS-Guideline, /66

Repeatedly, this does not succeed because of insufficient choice of words or for the lack of qualification of the participating persons. The used terminology does not fulfil to contain all necessary information, as shown in the following exhibit.

Figure8: Necessity of conceptual consensus

Consensus-building is a process of convergence, which aims to achieve consensual action: words should be interpreted and implemented in action, as the author has meant.

Contract

ContractSpecification

ProductSpecification

Planner(Tender)

Project Developer(Contractor)

DesiredSystem

ProposedSystem

?


OTS-Guideline, /66

Sequence 1: Problem Classification

Qualification Step: ¤ Urgency to Act

Creation of terms to classify problems P Vision of Solution

With this qualification step the user of this OTS-Guideline accomplishes a certain definiton to identify, classify and describe his problem and furthermore to reach a vision of solution based on this definiton. The OTS-Guideline provides a jump start in terms of definitions with which most of the users will most likely be faced during this sequence:

Following examples can be extended by the user:

Miscibility of Manufacturers

One requirement for the miscibility of manufacturers in the sense of OTS is the application of interfaces for the collaboration of those systems, which are compliant to the standardized and disclosed interface specifications (so-called communication standards). This is the only way to achieve the desired synergetic performance by using systems of different manufacturers.

Vendor Mixed Environment

…is the product of a mixed composition of a system’s components regarding the manufacturer, if a vendor mixed environment is implemented it has to be minded that this composition should be able to allow the addition of another component of an even different manufacturer later on.

OCIT®/OTS-Scenario

This term stands for approaches within the implementation of a vendor mixed environment based on OCIT®/OTS. These mixtures are offered to solve abstract, mostly political demands (e.g. reducing costs) resp. certain requirements like the claim for competition.

Support to develop a vision for solution is been given, if the user is able to fit his problems into such an approach.

OTS 2

OTS 2 allows a flexible adaptability to individual communication needs regarding quantity and quality. On the one hand this is done with the establishment of a consistent and continuous concept of structuring and on the other hand OTS 2 itself includes reference models for the realisation of add-ons.

As a result of this modular system, the following advantages arise:

Reduced scope of specification because of the reusability of existing OTS-Components

Flexible adaptability with new and existing OTS-Components within the OTS-Standard

Facilitation of manufacturer-independent expandability of the OTS-Standard due to integration of new OTS-Components

Clear conditions for testability/certification in consequence of the establishment of reference models for add-ons in the OTS-Standard

Therefor the standard qualifies itself in an optimal way for usage in a comprehensive integrated network.


OTS-Guideline, /66


Problem Evaluation: ¤ Urgency to Act

Classification of one’s problem with scenarios P Vision of Solution

Initial Situation

Certain requirements given to a user add urgency to the whole topic and are the trigger to put him under pressure (for examples from the environment of this Guideline see the table below). Now the user has to figure out how to comply with these requirements and how to evaluate decisions in this process. Therefor he has to be aware of a potential purchase and its activity, in other words he needs to build competencies and skills beyond his actual expertise.

Application Sequences

A classification of the problems coming from those requirements in OCIT®/OTS-Scenarios can be done by means of the following cluster. Is a classification possible, this OTS-Guideline can provide a scenario which will contribute to an appropriate solution.

Demand of … Why is there a compulsion to a vendor mixed environment1?

Typical OCIT®/OTS-

Scenario

Reduction of costs on the field level regarding need for renewal (control devices with new performance features, e.g. LED-technology)

Call for competition Scenario 1

Integration and Upgrading of the actual system (implementation of political parameters for better traffic conditions)

Technological change

i.a. call for competition

Scenario 1 and 2

Example: Renewal of centre technology (ageing, discontinuation)

Scenario 2

Improvement of working efficiency and ergonomics (new performance features, e.g. consistent configuration data exchanges, automatic control panels)

Technological change

i.a. call for competition in addition

i.a. call for interconnectivity in addition

Scenario 1 and 2

Participation in collaborative projects (local and intermodal traffic management)

Call for interconnectivity

i.a. technological change in addition

i.a. call for competition in addition

Scenario 3

Following scenarios may help to identify, characterize and classify your problem:

1 See Figure 1


OTS-Guideline, /66

Scenario 1:

Application of complete communication standards only

field level – centre level

The entry in a vendor mixed environment occurs with the implementation of the standard interface: traffic controller – traffic light control central (e.g. OCIT®-Outstations Standards). For instance a new traffic light control centre gets a centre-sided standard communication element, so that on field level standard-compliant traffic light control units can be installed too. Per definition those units would have a standard communication element and would be connected to the traffic light control centre.

In this scenario a large expertise is needed on the application level. In matters of the communication level no special expertise is necessary. However it has to be defined, which interface specification would be applied in a certain case setting up the scope of functionality concerning communication.

Scenario 2:

Application of complete communication standards only

application - management level

Additionally to the vendor mixed environment within Scenario 1 a standard has to be implemented within the management level (e.g. OCIT®-Instations). For example a quality control system or a “consistent configuration data exchange” would be added to an existing or even new traffic light control centre.

Referring to the application level, also in this scenario an extended expertise is requested. In sense of the communication level this basic scenario requires just the knowledge of which of the possible standard interfaces should be chosen. This knowledge and choice has to be subjected to the favoured application functionality.

Scenario 3:

Extension of the standard

management level

Scenario 3 is built on a more complex task compared to those before. For instance from the demand of availability of comprehensive traffic information compulsorily results the creation of an integrated network. That is due to the fact that the required traffic information cannot be provided by one of the involved scopes of application alone. First the information have to be merged and prepared.

The before mentioned integrated network is composed of already existing systems for the several scopes of application and new systems based on the traffic management level.

This time an extended expertise is needed regarding both, the level of application and communication. It needs to be determined, which standard is going to be applied. Therefor knowledge is required how to extend the standard to the data and protocol level.


OTS-Guideline, /66


Vision of Solution: ¤ Urgency to Act Description of the problem, the vision of solution

(i.a. alternatives) and the associated value

proposition P Vision of Solution

For the development of the vision of solution the OCA-Model delivers a MSWord-Template “system overview/interface specification” (for short SO/IS). Chapter 1 to 3 are relevant for this occasion:

Chapter 1 refers to the formal control of quality.

In Chapter 2 definitions of terms and references to certain documents are given.

Chapter 3 applies itself to the actual problem description and development of a vision of solution.

Like in all specifying quality artefacts of the OCA-Model, in the template “SO/IS” it is differed in terms of colour between certain texts.

This is part of the 1-document solution, with the help of which the different rolls and therefrom resulting views of a client on the one hand and an agent on the other can be comprehended in one document with different inputs (blue/black/red). Hence a common view on a to-be-realized system can be solidified.

The meaning linked to the diversification is introduced in the following part, while simply the most important terms are mentioned:

Blue text The blue text provides help with the application and interpreatation of the structure of the documens SSS and SO/IS (see MSWord-templates . SO/IS, SSS).

Black text With the structure of the documents SSS and SO/IS a room is fixed, in which the client-side user of this Guideline can place his idea of the intended system. The text colour of the client is always black. As part of a formal method the tender document is the black text.

The red text becomes its importance later, for what reason it will be introduced then.

Advice: How to describe a problem and how to get to a proper vision of solution?

The task of designing a system results in a system specification, which is used by the vendor during realization. Therefore, the specification has to provide the requirements on the realization without a doubt and furthermore, the client has to be able to check on the basis of this specification, whether the realization meets the requirements or not.

From experience, it is known that this is achieved infrequently. Because of linguistic differences, there is a gap between specification and the realised result. It is called the “semantic gap”, which has principal character and causes misunderstandings. Both sides believe to be distinct and do therefore see no need to evaluate their results.

It is a general advantage, if the realiser knows in detail, which problem has to solve and which values shall be achieved. In order to guide further procedures, the following questions will help:

1. Which dissatisfying condition causes the remodelling?

2. What kinds of consequences result out of this disfunction?


OTS-Guideline, /66

3. How do I envision a possible solution for this problem?

4. What kind of value and benefit result out of my desired solution?

These questions draft a framework to illustrate a problem description. But starting with question 3, answers get really complex because the desired system has to be sketched in a conceptual way. A certain terminology has to be created, which is able to effectively describe the vision of solution (especially for question 4). While working with these questions, specific questions arise and professional advisers can be consulted. Furthermore these four questions will make the user to try to get to the bottom of predefined solutions from vendors, who do not know the specific problem.

Classification and Identification are somehow related to each other. Problem classification means to identify the problem to be solved by the help of an already known (standard-) problem or pattern or to relate them. The OTS-Guideline provides different, typed scenarios. They reflect experiences of procurement actions and highlight typical areas of concern.

The client should have achieved the following bullet points at this stage (end of sequence 1):

Clarity on the requirements placed on him regarding the concretion by the person, who made them. Thus, clarity on the problem itself.

Vision of solution

A document, in which problem and vision of solution is defined.


OTS-Guideline, /66

6.2 Sequence 2: System Identification

Figure9: Application from system design to implementation, activities sequence 2

Sequence 2: System Identification¤ Vision of Solution


. Template Interaction Matrix

. Template SO/IS

Precise Vision of the

SystemP

System Modeling:

Modeling of the existing

system with the help of

existing metamodels

Iteration Step Bound:

What to renew?

What to preserve?

What are the system

boundaries?

i.a. development of

alternatives

Vision of the System:

Documentation of the

precise vision of the

system

Concretion Step:

Develpment of an

interaction matrix for every

alternative, Evaluation of

the alternatives on high

altitude

Qualification Step:

Creation of terms for

system identification


OTS-Guideline, /66

Sequence 2: System Identification

Qualification Step: ¤ Vision of Solution

Creation of terms for system identification P Precise Vision of the System

With this step of qualification the user of this Guideline creates himself a term to identify, shape and add new components to his own system. Now he is able to phrase and describe an intended vision. The OTS-Guideline provides initial aid in terms of definitons, with which most users will see theirselfs confronted:

System

System is the term for every structure, which helps to solve a holistic problem, e.g. a traffic signal control system, a traffic management system, or public transport system.

A system can interact with others and its environment via interfaces. Out of a technical point of view a system should be semantically seen as a subsystem. So other subsystems with which the actual subsystem is interacting and the actual subsystem itself can be seen as parts of a greater integrating system. Categories of subsystems can be introduced, which group subsystems by superordinate considerations. Such categories should be classified as application domain resp. scope of application.

System Boundary

A system boundary separates the system from its environment. Every subsystem has its own system boundaries, for which it has to be determined, which functionalities are included or not. The boundary of the overall system is spanned by the aggregation of all subsystems.

Subsystem

Subsystems are parts of a system, with which usually certain functionalities are aligned. They can stand in mutual relations and be understood as part of a greater (sub-)system. The classification by greater aspects (e.g. scope of application) is possible.

The specification of subsystems is beneficial for lot-building in a delivery transaction with several clients. This however assumes that the relations between all subsystems are proper specified.

Subsystems are important for the implementation and the structuring of interfaces in functional and logical aspects.

The OCIT®-Instations system model defines for instance following subsystems for a traffic light control system: traffic light control centre with OCIT®-interface, OCIT®-controller, quality management system.

The OTS-model defines for instance following subsystems for the local traffic management: strategy management (local), Content-Centre traffic data (local), traffic models, process indicator system, detection centre (local), traffic light control centre (local), influence on route-planner.

Communicative Relation

Common appellation for an interactive relation between subsystems or components, which is not yet deeper specified. Essential part of an as-is analysis is e.g. the gathering of communicative relations to the analysed subsystem.


OTS-Guideline, /66

System Performance

With help of an interactive user’s interface at the “system boundary” of a system, the user is able to access the system performance, which consists of the performance of individual subsystems, which are therefore communicating with each other.

Network system

Due to the combination of subsystems to a network system, system performances shall be able to be realized and also used, which are only possible with the synergetic cooperation of those subsystems. The collaboration is done through communicative relations. Synergetic performances can be used at “system boundaries” of subsystems, as showed in this figure:

Figure10: Network system

Component

A component is basically an existing part of a subsystem, with which a specific functionality is realised. The access to this functionality is done through a provided interface. Those interfaces are specifying services needed to perform.

Advice: What is a model?

A system is a real or imaginary object, which is logically matching and in a mutual correlation with its environment. The term “system” serves as a semantic classificatory. Existing system instances can be identified, if they show these characteristics, for example:

This “is” a traffic light control system, because there is a control element, which controls all traffic light systems and because it can interact with a superior control centre.

Model describes a self-contained, semantic abstraction of a system. Certain aspects are analysed, which are fundamental for understanding the system or a central point of the description. Therefore, the semantics of a system is delineated by several models.

A system specification describes the essential requirements or features of a system, which are sufficient to realize the system. The realised solution shows additional features by means of the used realisation method.

The description of a system is always a model of a system, a so called system model. Consequently, the specification of a system is a system model.

Is system mentioned within the OTS-Guideline without any attribute, then a to-be-realised system (technical artefact) is meant. A subsystem specification, which describes the result of reorganisation, renewal or expansion, is a pre-given display format for a model of this system.

Before the actual results are realised, models and subsystem specification must be created,

subsystem

subsystem

subsystem

subsystem

Communicative relationUser

System performance

network system


OTS-Guideline, /66

which illustrate the ideas about the desired design non-ambiguously. This is difficult, especially when values must be formulated with the actual design of the system. Scalability, for example, is understood today in a different way than before, because the technology has changed. Especially when the reorganisation has to be done on old parts of the system, values, associated with these parts, need to be reinterpreted. Other examples are extensibility, integration, flexibility or maintainability.

If a certain terminology has established with vendors’ products, it is even more difficult to separate from this specific terminology and the associated values to eventually embark on a neutral level of description. This has to be done by the help of an objective model level, where system and values must be described by semantically reconstructed concepts. It is useful to use the general ontology understanding. This can be limited to the following features:

There is a need expressive (semi-) formal description language.

Semantic features of terms (catchword) shall be definable.

Relationships between terms (semantic structure, syntax) have to be producible.

Formation of terminology hierarchies (upper, narrower terms) has to be possible.

Recognition and consensus in a community has to be producible.

These requirements are largely met by UML. However, one must learn to use this language for this purpose.

Models represent different views for example on to be created reality. For the presentation and description of such models, model elements and relationships are needed as semantic support. For their definition a meta level, the model meta level, is taken. The explicit approach thus supports the transferability of modelling knowledge. The recipient of this model can for example only check it for semantic correctness, if it has a corresponding meta model, on which consensus was reached before.

The specification of a system inevitably involves a description of the system environment into which the system realisation shall be integrated. It will be concentrated on the interaction forms between the realisable system and its environment, which include existing or to be implemented neighbouring systems.

Only the sum of all views, i.e. models, approximately gives a picture of what a system "is" or should "be".

The functionality illustrates a functional perspective, as a model. Model elements that represent functional units, abstract from the technical construction. A functional model of the "actual" system can be compared to a functional model of the "target" system. Doing so, one would compare the functional units and classify the differences. For example, one will try to determine “same”, "different", "more" and “similar”. This is the beginning of determining the boundaries of the target system to be specified.


OTS-Guideline, /66


System Modelling: ¤ Vision of Solution

Modelling of the existing system with the help of existing meta models


The modelling of the application area in an appropriate system model in order to identify subsystems is essential to picture and coordinate the establishment of systems of different manufacturers with standardised interfaces.

For this purpose you need to graphically describe the existing and installed system on the client’s side (actual system). Now the system can be changed, extended or replaced. In any case both, the subsystems and interfaces of the actual system have to be identified.

By using connection icons (lines, arrows) it should be visible, which subsystems of the actual system have a mutual, communicative relation. A reference to communication- or interface standards can be shown with the help of an inscription of these icons.

The OTS-system model and the OCIT®-Instations system model provide a Guideline, how to bond differentiated functionalities to subsystems.

Note: The next step is facilitated, if it is made via completely defined interfaces, whose specification is available. Meaning all participants can read them and give them as part of the specification to potential providers.

Advice: How do I recognize system boundaries and communicative relations?

The logic system boundary as described above does not necessarily represent the technical system boundary. The technical system boundary is different from the logical system boundary due to the system interfaces. They define how the target system and the actual system will be interactively connected.

Existing standards (open or proprietary) and their quality may influence the decision. It might get necessary to generate and value case studies for boundary setting. The assessment can be significantly influenced by the strategy, how the solution of the design task is placed in a local context. Furthermore, how important aspects of system complexity, such as scalability and maintainability, is attached. In any case, the communication and interaction between subsystems moves into focus.

Advice: Are there existing meta-models (see Figure 3) for system modelling?

In order to specify the mixed vendor design of a traffic control and / or traffic management system and the associated interoperability between the participating subsystems, it is helpful, if their own ideas are comparable with existing, well-known system structures or can be oriented to them.

The OTS system model supports this matter. It identifies subsystems that are supposed to manage several tasks in a system environment (e.g. Dusseldorf) and which are interdependent.

By the help of the OTS system model (see Figure 3), so called OTS communication standards, it can be identified, which are already used for communication between subsystems.


OTS-Guideline, /66


System Breakdown (Iteration): ¤ Vision of Solution

What to renew?

What to preserve?

What are the system boundaries?

i.a. development of alternatives


First of all the rough requirements on the new system should be evaluated by use of the following questions:

For what features or subsystems should the system be extended?

Which features or subsystems should be renewed?

Which features or subsystems should be preserved?

The model of the existing and installed system on the client’s side, constructed before, is now used to shape the new vision of the system in an iterative process. It is analysed, where components will be removed or new components will mutual interact with older ones to ensure the desired functionality of the system.

These components can be certain functionalities, which i.a. can be combined to one or more subsystems. Or whole subsystems, in case it is already known how it is done. Every subsystem has its own system boundaries, for which it has to be analysed, which functionalities are included or not. The boundary of the overall system is spanned by the aggregation of all subsystems.

It should be transparent, which components of the application area are assumed (subsystems and interfaces of the actual system) and which have to be realised.

Connection icons illustrate, which of the new components are in a mutual relation among each other or with already existing subsystems. A relation to communication- or interface standards can be shown by inscriptions.


OTS-Guideline, /66


Concretion Step: ¤ Vision of Solution Development of an interaction matrix for every

alternative, Evaluation of the alternatives on high

altitude P Precise Vision of the System

The development of an interaction matrix for every alternative of the shaped system model is useful in the sense of concretion of the to be shown relations between old and new, extended subsystems. For this matter the OCA-process model provides a certain MSExcel-template . - the interaction matrix (IM).

The format of the interaction matrix exemplary shown below allows to split every application area in subsystems and differ them regarding components. The matrix field at the intersection of column and row helps to put components in a communicative relation.

Now it is time to evaluate every system alternative by strategic goals and requests. By chance it should be discussed, which opportunities and threats are opening up behind every alternative? In addition to the interaction matrix, the graphic system alternatives provide help.

The following questions might give a key impact for the decision on which alternative to take:

How many suppliers are able to realise the new functionalities and subsystems?

Can the new subsystems be connected to open interfaces?

Are there threats regarding the interoperability between the subsystems of the actual system and the new subsystems (e.g. support of existing functionalities)?

Is the new alternative compatible for an upcoming expansion of the system (e.g. expansion to a traffic management system)?

… … …

Teilsystem Komponente

Ko

mp

on

en

te 1

Ko

mp

on

en

te 2

….

Ko

mp

on

en

te n

…

Ko

mp

on

en

te 1

Ko

mp

on

en

te 2

….

Ko

mp

on

en

te n

Ko

mp

on

en

te 1

Ko

mp

on

en

te 2

….

Ko

mp

on

en

te n

…

Ko

mp

on

en

te 1

Ko

mp

on

en

te 2

….

Ko

mp

on

en

te n

Ko

mp

on

en

te 1

Ko

mp

on

en

te 2

….

Ko

mp

on

en

te n

…

Ko

mp

on

en

te 1

Ko

mp

on

en

te 2

….

Ko

mp

on

en

te n

Komponente 1

Komponente 2

….

Komponente n

… …

Komponente 1

Komponente 2

….

Komponente n

Komponente 1

Komponente 2

….

Komponente n

… …

Komponente 1

Komponente 2

….

Komponente n

Komponente 1

Komponente 2

….

Komponente n

… …

Komponente 1

Komponente 2

….

Komponente n

Feld

eb

en

e

Teilsystem 1

Teilsystem n

Teilsystem 1

Teilsystem n

Verk

eh

rsm

an

ag

em

en

t-

Eb

en

e

Teilsystem 1

Teilsystem n

von nach

Zen

trale

Eb

en

e

Anwendungs-bereich

Leit

eb

en

e

Feldebene

Teilsystem 1 Teilsystem n

Verkehrsmanagement-

EbeneZentrale Ebene

Teilsystem 1 Teilsystem n Teilsystem 1 Teilsystem n


OTS-Guideline, /66

Are there enough resources regarding data usage, communication volume etc.?

Is a high financial input expected?

etc.

In case a particular alternative is preferred, you can start with the next step – documentation of the vision.


OTS-Guideline, /66


System Vision: ¤ Vision of Solution

Documentation of the precise vision of the system P Precise Vision of the System

The black text initiates the documentation of the desired vision of the system. It is done in the document SO/IS in chapter 4.

The total scope regarding the desired vision of the system is described, meaning the client inserts the picture of the new system model added by a commentary.

Like in the model of the vision of solution the user should get a clear idea of which parts of the scope are assumed (subsystems and interfaces of the actual system) and which have to be newly implemented.

The client’s ideas of connection icons, defined in the system model of the vision of solution, are determined in the section „Identification and declaration designated types of interface”. The table below gives an impression of how it is done. Potential agents can add their opinion regarding the client’s comments (red text2). Another table provides the opportunity to add all essential types of interfaces or their specification. (part of . template SO/IS)

Mutual relation Type of Interface Comment

Subsystem 1 Subsystem 2

Subsystem A Subsystem B OTS 1.0 <black text>

<red text>

Subsystem C OTS 1.0 <black text>

<red text>

Subsystem B Subsystem C OCIT®-Instations PD <black text>

<red text>


Construction of a system model of the actual system

Idea on the future system architecture and on the changes necessary to the actual system (e.g. integration of new subsystems, new interface etc.)

A system model of the future system and a precise vision of the system

A document, in which all models and visions are described

2 Explanation in sequence 4


OTS-Guideline, /66

6.3 Sequence 3: Requirement Specification (Contract Specification)

Figure11: Application guidance from system design to implementation, activities sequence 3

Qualification Step:

Learn how to construct a

requirement specification

Sequence 3: Requirement Specification (Contract Specification)¤ Precise Vision of the System

P Publication of the Completed Subsystem Specifications

. SO/IS . SSS

. SD . Glossary

Publication:

Publication of the

subsystem specification

during the announcement

Published Subsystem

Specification(s)P

Requirement Specification:

Creation of a black text for

all to-be-updated systems


OTS-Guideline, /66

Sequence 3: Requirement Specification (Contract Specification)

Qualification Step: ¤ Precise Vision of the System

Learn how to construct a requirement specification P Publication of the Completed Subsystem Specifications

With this qualification step all fundamentals necessary to create a requirement specification are set. Certain terms with which the user will see himself confronted are introduced.

Stakeholder

Stakeholders are persons, institutions and companies etc., who have an essential impact on the development of a product (subsystem). In the sense of this Guideline this are for instance road authorities, operators, funding bodies etc.. However they are not using the subsystem but have a higher interest in it.

User

A user is a specific stakeholder, who is interacting with the to be specified subsystem. He can be assigned to a stakeholder.

Users are classified due to their user roles. Often individuals cover different scopes and therefor take several roles.

Protagonist

A protagonist is a human or technical (another system) user. The protagonist interacts with a system to achieve a certain objective and anticipates certain behaviour during the interaction.

Objectives and Desires

Stakeholders and users are sources of objectives and desires (“stakeholder needs”). They have to be clearly differed from features. While objectives and desires of different stakeholders can compete against each other, the features have to be unambiguous.

Features

Features describe the expected capabilities of a product or project. They can be split in functional, qualitative and quantitative features.

Core Functionality

Requirements of stakeholders, who use the system not directly, are denoted as core functionalities. These are essential functions, with which the actual application of the system is met, and can be described.

Use Case

Use Cases describe the interaction between a system and a protagonist. This interaction is always triggered by the protagonist. The following steps are necessary to identify use cases:

Identify the system to interact with.

The boundaries of the identified system need to be determined. Since it defines the interface, by the help of which it is interacted. In other words, mostly identical systems can behave completely different, if system boundaries are not set equally. Following questions may help to determine these boundaries:

What is still part of the system? System boundaries are put into text.

Who is triggering the interaction? Which information are provided? Identification of other protagonists.


OTS-Guideline, /66

Use Cases are specified.

After system boundaries are determined and the protagonists are identified, the use cases can be created. Since every protagonist has his objectives and therefor is interacting with the system, use cases can be found by examination of the protagonists. “What is the protagonist’s objective?”, “What does the protagonist want the system to do?”. The use case’s name should be chosen regarding the objective of its protagonist.

To simplify the creation of the use case the same table as for requirement specification should be used. (. template SSS)

Trial

A trial is the proof that a subject matter is working compliant to its specification. This conditionally asks for the determination of the subject matter and the correct behaviour prior to the trial run.

Testing requires

the creation of the desired behaviour through targeted stimulation of the system,

the observation of the real behaviour of the system and

the comparison / assessment of the observations and features.

Correlations are shown in the following figure:

Figure12: Trial of a test object

Ability of stimulation

The ability of stimulation is a characteristic, which is required, if a stimulation of a subsystem or its communicative relations to other subsystems is needed for test purposes.

The stimulation has to be performed effectively in order to generate test sequences and test results quickly and easily. Furthermore the stimulation has to be reproducible in order to repeat the test in the event of an error (whereas it is the requirement that the individual test results should be independent as far as possible).

Test Object

Re

qu

ire

me

nts

ObservationStimulation

Only (effective) stimulableand observable systems can be tested!

RequirementSpecification

Solution Specification


OTS-Guideline, /66

Observability

To make a target-actual comparison, the system behaviour regarding every test must be observable.

The monitoring should directly reflect the results of a test case. Indirect observations are possibly defective and the cost of interpretation would increases. The information should be shown particularly in a form that allows a correct assessment (plaintext). An application-based examination of the observed results would be ideal.


OTS-Guideline, /66


Requirement Specification: ¤ Precise Vision of the System

Creation of black text for all to-be-updated systems P Publication of the Completed Subsystem Specifications

A requirement specification (black text) needs to be created for every subsystem. The reason for that was already described in chapter 5.1.8. The following approach has proven itself (see . template SSS). Since chapter 1 of SSS is irrelevant for this topic, it is skipped and this sequence starts with “declaration of technical terms, links to references”. Assistance for the application and interpretation of the content are given in blue text.

Declaration of Technical Terms, Links to References

In this chapter all technical terms, which are not general knowledge or do have a certain meaning for this content, are defined. In case that the explanation needs to be detailed and for this reason needs more space, it can be extracted to an external glossary (see . template SSS).

Furthermore external documents with a crucial meaning, like for example standards, city specific conventions etc., are listed and an indication of source is added.

Introduction to the Problem

During this section the key understanding for the pursued solution should be build. Out of the scope’s view, the technical problem is described and set in relations with stakeholder interests:

1. First of all objectives and purposes of the pursued system solution are specified. The purpose may be a target itself or be dedicated to tracking a target. The essential alternatives given through the pursued system solution are described quite basically. These may be functional characteristics or technical features, which highlight qualitative aspects of the solution.

2. By the classification into a certain scope of application (e.g. traffic light controlling, traffic management, traffic data gathering etc.) the scope, in which the pursued system solution should be integrated, is confined.

3. The problem is described, by first describing and discussing the undesirable condition and who is affected by it and maybe even suffering. The resulting consequences and the benefit resulting from the disposal of non-desirable state motivate the desired system solution or make it understandable for others. The breakdown of the problem description should be made as follows:

Problem statement

The not desirable state and its impact is described at this point (for example, high operating costs).

Solution/Motivation

The coarse vision of solution (i.e. alternatives) and associated benefit (e.g. reduced operating costs) are described.

Differentiation of Benefit

This bullet point can be used for a further differentiation of the benefit (e.g. economic importance, attractiveness etc.).


OTS-Guideline, /66

Condensed Meaning

The condensed meaning of the desired system solution is conciliated on a high abstraction level by the provided table. All interested parties involved (stakeholders) will be informed why the solution described above is sought.

4. By the superior classification of the subsystem in the scope of application happens another characterization of the subsystem regarding its scope. The following aspects purport a decision framework:

Role(s) of the subsystem

Which role(s) takes the system within a certain context (e.g. traffic light controlling, urban traffic management)?

Classification of the subsystem within the scope of application

For the classification of the subsystem in the application domain the system model regarding the vision of solution, developed in the sequence "system identification", is used and explained. While explaining the graphic it should come clear, which parts of the scopes are assumed (subsystems and interfaces of the actual system), which need to be re-implemented and where mutual relation to other subsystem arise.

Main benefit and capabilities

The main benefit and all essential abilities and characteristics of the subsystem should be described at this point. A reference for the evaluation of the interpretation of the meaning of the capabilities and characteristics is provided. The description is intended to build on a general level of understanding and support the preparation of references to objectives and desires of stakeholders and users.

Assumptions and Constrictions

Such points will be outlined, which can stand in the way or alter the desired system solution. Previous knowledge on an existing initial system or on the system’s environment is brought in. It is obviated to the argument “I should have known!”.

5. Definition of the stakeholder and their interest in the subsystem

All stakeholders are mentioned, who are origin for objectives and desires. These in turn are interpretation keys for the later described requirements for the realizer resp. agent. The stakeholders are pictured by the following approach:

Overview (Declaration of stakeholders)

A stakeholder is declared and individualized by name, roles and sphere of interest. For example: City X, represented by authority Y, is operator of the subsystem and has an interest in warranty of security and comfort in traffic flow.

Is it predictable that the stakeholder declaration will fill a lot of space and therefor the system specification tends to get confusing, these can be extracted to an external stakeholder document (see . template SD).

A description on how to declare stakeholders and on how to fill the document you will find in the appendix.


OTS-Guideline, /66

Stakeholder Name Role

Stakeholder category City, Country, Company

Explanation of the role of the stakeholders themselves or as a delegate for others in the context of the to be specified subsystem, as well as the requirements that arise from this role.

Example:

Road authority civil engineering department x, city x

Responsible for planning, construction and maintenance of the System; responsible as the owner for the design, procurement, processing, construction supervision and acceptance of the system and the requirements that arise from this role.

Stakeholder profiles (optional)

If it should come apparent for what sake stakeholders are acting, participating and which outcome is connected to the solution, it is necessary to have a specific profile for each stakeholder. The following table may provide help doing so:

Representative

Description

Type

Responsibility

Criterion of Success

Involvement

Expected Results

Comments / Problems

Is it predictable that the stakeholder profiles will fill a lot of space and therefor the system specification tends to get confusing, these can be extracted to an external stakeholder document (see . template SD).

Objectives and desires of stakeholder

All objectives and desires are listed and briefly described for every particular stakeholder. Contradictions may occur, as the stakeholder cannot review this list. Therefor a comprehensive requirement analysis has to be done in order to maybe adjust the made assumptions.

Example: road authority

Target / Desire Comment

Security of Investment, Sustainability

The system has not just to meet today’s expenses, furthermore it has to be expandable for requirements regarding traffic technology and system technique (time horizon of ten to twenty years).


OTS-Guideline, /66

Definition of users and their interest in the subsystem

All users are mentioned, who are origin for objectives and desires. These in turn are interpretation keys for the later described requirements for the realizer resp. agent. The users are pictured by the following approach:

Overview (Declaration of users)

The user role is declared, briefly described and assigned to a stakeholder. An example is given by the following table:

Name Description of the Role Stakeholder

Role name of the user

Description of the role, which is taken by the user in context of the to be specified subsystem

To which stakeholder can the user be assigned?

Example:

operator Ensures the availability of the system and introduces the measures for traffic safety associated with the system. Essential tasks are surveillance, manual intervention and initiation of measures for troubleshooting.

Operator

At this point it is highly recommended to introduce the user role “tester”. By this role the requirement specification is extended with requirements to the trial of a subsystem.

User profiles (optional)

It is necessary to describe the specific profiles of the user roles in order to illustrate them. This will point out with what interest a user acts, engages himself and what results he expects.

Representative

Description

Type

Responsibility

Criterion of Success

Involvement

Expected Results

Comments / Problems

User objectives and desires, user working environment

The specific user objectives and desires related to the subsystem deeper specified. This shall develop a clear understanding of why the user has a certain requirement to the subsystem and what he expects to result from this.

Furthermore, information on the users environment are conciliated.


OTS-Guideline, /66

Example: operational operator

Objectives and Desires:

Target / Desire Comment

comfortable surveillance The operational state of the systems on field level, communication systems and the central level needs to be clearly pictured.

In the case of a dysfunction, qualified data and information on the error must be available very quickly.

If necessary, the visual design of the praphical interface should be agreed upon with other users.

The presentation and output messages must be parameterisable for the user.

Working environment:

Office environment with a PC connected to the urban network

Capabilities and Characteristics

The chapter “Capabilities and Characteristics” describes requirements to the subsystem resulting from stakeholder and user objectives resp. desires. In order to comply with the vendor mixed environment, the requirements and the behaviour during interaction of every subsystem needs to be carefully and detailed described. It should be assumed that every requirement, which is not described is not compatible or not executed the way oneself expects.

In terms of a trial or approval of the subsystem and its communicative relations to other subsystems it is important to have all requirements described in a testable way. Otherwise an efficient trial or approval is not ensured:

non-testable – „Controller X has to react fast and appropriate“

testable – „Controller X has to react to occasion Y within 0,1 seconds“

The following types of trial and approval help to classify the requirements. In addition they make it easy to calculate the scope of the trial resp. approval:

Evaluation (E): The assessment is performed by an expert evaluation of the customer / client. It can for example be used to approve non-testable / verifiable requirements.

Measurement or allowance (M): The measurement or the allowance concerns the verification of compliance with given quantity structures and other measurable characteristics that are specified in the non-functional requirements. In case the requirements are classified with non-testable information or the cost of measurement is disproportionally high, the measurement can be replaced with an evaluation or a combination of both (M).

Acceptance trial (A): For all use cases, all requirements non-testable by measurement or allowance and interface-trial, test scenarios need to be specified. These test scenarios as well as the necessary test data are created by the contractor in close collaboration with the client. For every acceptance trial it needs at least to be determined:

if they are executed completely or in samples,

the necessary conditions for their implementation (trial frame, participating systems and components, coverage data, tools, …),

the execution,

expected results,


OTS-Guideline, /66

when a trial is classified as passed, partially or completely failed,

the way of documentation of the execution and results of the acceptance trials.

Warranty (contractor sided) (W): The client abstains from one of the above tests, as their execution is economically not feasible for the client as well as for the contractor. (example: expandability to X LSA)

not relevant (N): texts are just for explanation

Furthermore, the user "tester" should be guided by the following questions in the specification of its role-specific requirements:

How does the tester imagine the process of the field- or acceptance test? Meaning what is tested when and how? (q.v. Sequence 7: F and Sequence 8: )?

How does the tester imagine the rough test scenario for a certain requirement?

Are functionalities required, which support the testability of the system (e.g. test tool)?

Which parts of the subsystem should be tested, i.e. being stimulated and evaluated?

Who takes the tester role? Client, contractor or a third party?

Note: At the request of the client, the contractor may be responsible for the creation of test cases or test scenarios, which then are created in the specification phase. Also in this case the client must take a position in his particular system specification to the five points mentioned before thus the test effort can be estimated by the contractor.

The chapter capabilities and characteristics differs between „functional requirements“ and „non-functional requirements“:

functional requirements

Overview of the functional requirements

Functional requirements out of different interests are made to the subsystem. In order to get an overview, these are illustrated in a chart, exemplarily shown in the TSP template. Following requirement types are differed:

o Stakeholder requirements, which indeed do not use the subsystem directly, but do have a higher interest in it.

Core functionalities, thus the subsystem itself achieves an own purpose

Requirements to connect it to other subsystems, thus it is integrable into a certain environment and complies a composite purpose in collaboration with other subsystems. Given this situation, the subsystem may ask for requirements to other subsystems, to be able to perform in the requested manner.

o Requirements of protagonists, who are, if necessary, associated with use cases, differed by

User requirements, who actually want to use the subsystem. These are described as requirements to user interfaces.

Requirements of other subsystems, which want to interact via exterior interfaces. These are described as requirements to exterior interfaces.

Stakeholder requirements

All functionalities, representing the case of the participating stakeholders, are mentioned here. On the one hand these are core functionalities, by the help of which the actual purpose of the system is achieved. On the other hand these are


OTS-Guideline, /66

functionalities for the connection to other subsystems (e.g. OCIT®-central system access, OCIT®-Outstations etc.). A grey-box-view is intended.

User requirements

Functional user requirements with ideas of users to interact with the subsystem are described. Via use cases, the requirements to the behaviour of the subsystem can be specified in more detail. Therefore see the correspondent chapter.

Functional requirements of other subsystems

Requirements of other subsystems to the to-be-specified subsystem are listed and explained. The description should reveal the functionality. Via use cases, the requirements to the behaviour of the subsystem can be specified in more detail. Therefore see the correspondent chapter.

Functional requirements to other subsystems

Requirements to other subsystems are listed and explained. The interaction matrix, created in during sequence „system identification“, delivers a good overview. The description should reveal the functionality. Via use cases in the requirements of each other subsystem can be specified more precisely.

Use Cases

Functional requirements are the starting point of a use case specification. The name of the use case is chosen according to the protagonist’s target. The specification of use cases should be done on the basis of the table provided in the TSP template. Note: In case there are no precise ideas on the use cases, this can be done during the performance specification in cooperation with the contractor. Thus the latter can calculate the needed input, the to-be-specified use cases should be in tabular form.

Non-functional requirements (qualitative, quantitative)

Precise characteristics of the scope of delivery need to be derived from the quality characteristics and requirements described in the following. Their existence is connected to a certain verifiability (allowance, testing conditions). System features, i.e. characteristics specifying the system, should be understood as quality characteristics. The grade of compliance of “quality characteristics and requirements” refers to the tender evaluation and has its impact on contracting.

This chapter may allude to the following exemplary topics.

Global characteristics

o Notable standards, norms, Guidelines

o Consistent operating philosophy

o Availability, reactions on breakdowns of components

Characteristics of technical interfaces

o Hardware interfaces

o Software interfaces

Integration characteristics and reactions on impacts

o Conditions at the point of installation

o Energy Supply


OTS-Guideline, /66

Delivery Conditions

In this chapter other requirements are listed, which allude to delivery of documentation or performance, which the client has to provide, as there are:

Acquisition, external development

Software-Installation

Documentation requirements

Note: If several subsystem specifications are created within an overall system, a quality assurance is required after the completion. Especially the mutual requirements of the subsystems needs to be reviewed.


OTS-Guideline, /66


Publication: ¤ Precise Vision of the System

Publication of the subsystem specification during

the announcement P Publication of the Completed Subsystem

Specifications

Competitive dialogue

1. 1. In the case of particularly complex contracts, Member States may provide that where contracting authorities consider that the use of the open or restricted procedure will not allow the award of the contract, the latter may make use of the competitive dialogue in accordance with this Article. A public contract shall be awarded on the sole basis of the award criterion for the most economically advantageous tender.

2. Contracting authorities shall publish a contract notice setting out their needs and requirements, which they shall define in that notice and/or in a descriptive document.

3. Contracting authorities shall open, with the candidates selected in accordance with the relevant provisions of Articles 44 to 52, a dialogue the aim of which shall be to identify and define the means best suited to satisfying their needs. They may discuss all aspects of the contract with the chosen candidates during this dialogue. During the dialogue, contracting authorities shall ensure equality of treatment among all tenderers. In particular, they shall not provide information in a discriminatory manner which may give some tenderers an advantage over others. Contracting authorities may not reveal to the other participants solutions proposed or other confidential information communicated by a candidate participating in the dialogue without his/her agreement.

4. Contracting authorities may provide for the procedure to take place in successive stages in order to reduce the number of solutions to be discussed during the dialogue stage by applying the award criteria in the contract notice or the descriptive document. The contract notice or the descriptive document shall indicate that recourse may be had to this option.

5. The contracting authority shall continue such dialogue until it can identify the solution or solutions, if necessary after comparing them, which are capable of meeting its needs.

6. Having declared that the dialogue is concluded and having so informed the participants, contracting authorities shall ask them to submit their final tenders on the basis of the solution or solutions presented and specified during the dialogue. These tenders shall contain all the elements required and necessary for the performance of the project. These tenders may be clarified, specified and fine-tuned at the request of the contracting authority. However, such clarification, specification, fine-tuning or additional information may not involve changes to the basic features of the tender or the call for tender, variations in which are likely to distort competition or have a discriminatory effect.

7. Contracting authorities shall assess the tenders received on the basis of the award criteria laid down in the contract notice or the descriptive document and shall choose the most economically advantageous tender in accordance with Article 53. At the request of the contracting authority, the tenderer identified as having submitted the


OTS-Guideline, /66

most economically advantageous tender may be asked to clarify aspects of the tender or confirm commitments contained in the tender provided this does not have the effect of modifying substantial aspects of the tender or of the call for tender and does not risk distorting competition or causing discrimination.

8. The contracting authorities may specify prices or payments to the participants in the dialogue.

In the context of public procurement law, the tender documents will be made available depending on the award procedure.

Figure 13: Procurement procedure VOB/VOL, distribution of tender dossier

Following tender documents needs to be made available by the advertising institution:

Cover letter

Service description

Service specifications

General and specific contract conditions

Model contract incl. stipulations (z.B. EVB-IT)

Complementary description of the actual system (e.g. interaction matrix, Glossary, proprietary description of interfaces)

Criteria for the evaluation of tenders (see sequence 5)

etc. specific documents according to the tender required by each country (e.g. see VOB/A §10, VOL/A §9 for Germany)

Tender

Steps

Contract Notice

Selection Process

Distribution of

Tender Dossier

Bidder Requests

Tender

Reception and

Evaluation

Award of the

Contract

Contract

Processing

Public call for

tender

EU: Open Procedures

Limited call for tender

EU: Restricted Procedure

with prior publication of a

contract notice

Direct award

EU: Negotiated Procedure


contract notice


EU: -

without prior publication

of a contract notice

Direct award




Announcement of the public call for tender

Reception of applicant forms / Selection of candidates Selection of candidates

Distribution of Tender Dossier

(e.g. Cover letter, specification, list of services, general and special contract terms, maintenance contract template incl. contractual arrangements (e.g. EVB-IT), complementary description

of the existing system (e.g. proprietary interface description), etc.)

Placing and clarification of bidder requests

Tender reception and submission

Formal assessment of tenders / Check of eligibility of the bidder

Calculative and technical check of tenders

Clarification discussion with bidders

Possibility for negotiation

Award of contract & Information of bidders incl. time limit of objections

Contract Processing

Creation of specification sheet, realisation, check and approval

Procurement Procedure VOB/VOLGerman thresholds for procurement procedures on EU level in the traffic sector VOB : 5.186 T€ VOL: 414 T€ (Date 01.01.2014)

EU: competitive

dialogue procedure

with prior publication


Negotiation of content

and price possible

BEFORE offer


OTS-Guideline, /66

For the service description the OCA approach provides the following documents:

Specifying quality artefacts, as system overview/interface specification (SO/IS) and subsystem specification(s) (SSS)

Supporting quality artefacts, as interaction matrix (IM), glossary (G) and the stakeholder document (SD)

Nevertheless, the client may still opt to create the service specification on the basis of other templates like MSExcel, ARRIBA or else.


Clarity on the requirements for the tendered subsystem(s)

Clarity on the requirements for the trial (e.g. what is the scope of the trial? Has the creator to develop the trial cases or is that duty of the client to specify?

Detailed documentation of the requirements for the tendered subsystem and its implementation in the overall system. (black text)

Publication of the requirement specification in the tender


OTS-Guideline, /66

6.4 Sequence 4: Tendering


Sequence 4: Tendering¤ Published Tender Documents

P Submission

. SO/IS

. SSS

. Glossary

Check of Black Text:

Check of client‘s

requirements and

answering of all

comprehension questions

Submission P

Creation Red Text:

Interpretation of client‘s

requirements by the

contractor and description

of how he wants to meet

those with the help of his

solution


OTS-Guideline, /66

Sequence 4: Tendering

Check of Black Text: ¤ Published Tender Documents Check of client‘s requirements and answering of all

comprehension questions P Submission

Does the contractor have received the tender documents of the client, the contents should be checked. Especially the service description documents created due to the OCA approach need to be validated:

Specifying quality artefacts, as system overview/interface specification (SO/IS) and subsystem specification(s) (SSS)

Supporting quality artefacts, as interaction matrix (IM), glossary (G) and the stakeholder document (SD)

In case of further enquiries regarding the required services, the client should be consulted.


OTS-Guideline, /66

Sequence 4: Tendering

Creation Red Text: ¤ Published Tender Documents

Interpretation of client‘s requirements by the

contractor and description of how he wants to meet

those with the help of his solution P Submission

The red text is a predefined font within the 1-document solution and helps to distinguish between the contractor and client (black text). While the OCA approach choses the red colour, it is not obligatory. In the end, the client may chose, which colour he likes most for what text.

In the occasion of a service description with a certain programme (functional tendering), the contractor must use red text in order to show with what solution he intends to comply with the requirements of the client.

This means that instead of a product document a convincing solution-approach should be created.

In case the formal proceedings permit it, the contractor may advise an in his judgement especially favourable alternative.

The contractor should understand the red text as a tool to point out, why the suggested solution is technically and economically the best.

From chapter 4 forward, red text has to be added to the to-be-specified quality artefacts of the OCA approach (SO/IS, SSS). The red text tells, with which components and interfaces the contractor complies with the client’s requirements. However, the client needs to decide on his own, whether he writes a red text for every single requirement or if he prefers to group them.

If technical terms, which are needed to understand the approach, are introduced, the glossary must be extended.

The contractor should have achieved the following bullet points at this stage (end of sequence 4):

Clarity on the client’s requirements for the system architecture (e.g. integration of new subsystems, new interfaces etc.)

Clarity on the technical implementation of the client’s requirements

Documentation of the technical interpretation of the client’s requirements. (red text)

Submission of the tender


OTS-Guideline, /66

6.5 Sequence 5: Tender Evaluation and Comparison


Sequence 5: Tender Evaluation and Comparison¤ Providers‘ Tenders

P Placing / Award of Contracts

Placing / Award of

ContractsP

Clarification of Contents of

Tenders:

Interview of potential

contractors by the client to

clarify understanding

issues relating to the

respective offer

Award of Contracts:

Awarding of the contract,

black text and red text get

to be integral parts of the

contract

Evaluation of Tenders:

Review of tenders by the

client


OTS-Guideline, /66

Sequence 5: Tender Evaluation and Comparison

Evaluation of Tenders: ¤ Providers’ Tenders

Review of tenders by the client P Placing/Award of Contracts

After their opening, tenders are evaluated. In compliance with formal legal aspects, the most efficient tender is to be detected. The following four test categories are differed.

Formal Check

The client has to check i.a. the timely receipt of the tenders, the absence of price quotations and signatures or the amendment of the biding documents. Formal incorrect tenders are excluded.

Qualification Test

The qualification test conduces to determine these companies, which can be considered to perform the requested services because of their expertise, ability and reliability. Furthermore, it helps to exclude the insufficient bidders. It is a business-related investigation, which aims to forecast whether a company is able to perform the order by its personnel, material and financial resources.

By judgement (e.g. of the German BGH), the qualification test does not supply an opinion on the qualitative differences between any given bidders. It is not compatible with the rating rules (e.g. of the German VOB) to accommodate different suitability levels of bidders in the decision to award the contract as part of the qualification test in such a way that the offer of a determined to be appropriate contractor is dropped in favour of a competitor mainly because of his higher rated suitability.

If the client wishes certain ability, the method of awarding contracts has to be chosen in a way that complies with these wishes. Especially the non-public call for bids, in case all requirements are met, is a proper way to do so.

After completion of the qualification test results cannot be adjusted anymore.

The qualification test is done at all occasions, which start with a call for competition.

Adequacy Check of Prices

The client checks the adequacy of the overall price to which the tender relates (no unit prices). Thus, a tender has to be excluded, which significant high or low price stands for no reason in an inappropriate ratio to the requested service. Checkable special conditions / discounts have to be provided, to justify the anomaly.

In order to prevent the exclusion, the suspicious bidder needs an explanation for his low prices. An exemplary reason may be a storage place which needs to be depleted. In any case, generalisations should be avoided, because the tender has to be excluded even if it eventually turns out that the anomalies were justified.

Economic Viability

There are just these tenders on the short list, which have, to put it simply, the best price-performance-ratio.

Here, the final price of the tender sure is an important criterion, but by no means the only one. In particular, the client is not bound to take the lowest price. the definition for public contracts literally say: “The lowest bid price alone is not decisive.”

Further characteristics of the offered service may be evaluated, as there is execution time, operating and add-on cost, design, profitability or technical merit. This value has to be clearly described in the tender documents, because the client is only allowed to evaluate on the


OTS-Guideline, /66

basis of already published criterions. Generally, there is an evaluation matrix provided to the contractor.

Are sub offers in terms of variations or alternatives allowed, they must be handled like the main offer.

The test of efficiency relates itself not to the competing companies but only on their offers.

Every previously introduced test is an independent and self-contained process, whose solution must be documented. Merging these tests is not allowed, neither is an amendment of the ranking order. Does an offer not comply to the requirements of the tests, it is excluded and not further tested. The following figure shows the placement of the tender evaluation within the award procedure.

Figure 16: Procurement procedure VOB/VOL, evaluation of tenders

Tender

Steps

Contract Notice

Selection Process

Distribution of

Tender Dossier

Bidder Requests

Tender

Reception and

Evaluation

Award of the

Contract

Contract

Processing

Public call for

tender

EU: Open Procedures




contract notice

Direct award



contract notice


EU: -



Direct award
















Contract Processing



EU: competitive

dialogue procedure




and price possible

BEFORE offer


OTS-Guideline, /66


Clarification of Contents of Tenders: ¤ Providers’ Tenders

Interview of potential contractors by the client to

clarify understanding issues relating to the

respective offer P Placing/Award of Contracts

Before awarding the contract, the client requires a clarification of contents of tenders with potential contractors in order to prevent lacks of clarity regarding their qualification. It is also allowed to discuss prices adequacy.

However, it is strictly forbidden to negotiate prices. The principles of a proper call for bids would be violated, if the client could negotiate after opening of the tenders. Therefore neither price deductions nor the well common 2% cash discount may be asked for.

The following figure shows the placement of the information discussions within the award procedure:

Figure 17: Procurement Procedure VOB/VOL, clarification of contents

Tender

Steps

Contract Notice

Selection Process

Distribution of

Tender Dossier

Bidder Requests

Tender

Reception and

Evaluation

Award of the

Contract

Contract

Processing

Public call for

tender

EU: Open Procedures




contract notice

Direct award



contract notice


EU: -



Direct award
















Contract Processing



EU: competitive

dialogue procedure




and price possible

BEFORE offer


OTS-Guideline, /66


Award of Contracts: ¤ Providers’ Tenders

Awarding of the contract, black text and red text get

to be integral parts of the contract P Placing/Award of Contracts

Finally, the most efficient tender gets the award. The reasons for awarding as well as for the denying of the other tenders are to be documented in the tender file.

By awarding the contract it simultaneously gets valid, unless the client has made adjustments like extensions, constraints or amendments. In this case, the contractor has to agree first.

The definition for public contracts demands that the client sets a fix point in time for the award of contract. In case he does not maintain this date, the contract gets not valid before the contractor agrees with it.

If the client asserts that he cannot award the contract in the prescribed period, he must ask for an extension of the contract period. If the contractor agrees, he is also bound to his offer during the extended period. If he declines the extension, his tender will not be considered anymore.

The following figure shows the placement of the awarding within the award procedure:

Figure 18: VOB/VOL award procedure


Evaluation and comparison of all tenders

I.a. solving of understanding issues

Award of contract

Tender

Steps

Contract Notice

Selection Process

Distribution of

Tender Dossier

Bidder Requests

Tender

Reception and

Evaluation

Award of the

Contract

Contract

Processing

Public call for

tender

EU: Open Procedures




contract notice

Direct award



contract notice


EU: -



Direct award
















Contract Processing



EU: competitive

dialogue procedure




and price possible

BEFORE offer


OTS-Guideline, /66

6.6 Sequence 6: Solution Specification (Performance Specification)


Sequence 6: Solution Specification (Performance Specification)¤ Granted Award

P Realisation Parameters

. CM

Realisation ParametersP

Solution Specification:

Further Specification by

the contractor, with the

help of which the agreed

upon solution is

concretised


OTS-Guideline, /66

Sequence 6: Solution Specification (Performance Specification)

Solution Specification: ¤ Granted Award

Further Specification by the contractor, with the

help of which the agreed upon solution is

concretised P Realisation Parameters

The solution specification – equitable to performance specification – sets the requirements to the to-be-created subsystem. The user requirements are specified and in an extension, implementation requests are further described supported by precise approach. In the performance specification is defined, how and where the requirements have to be implemented.

The contractor’s target now is to develop a preferably complete, consistent and distinct product definition out of the subsystem specification of the client. As a result, this product definition is the basis for the to-be-created subsystem. The subsystem specification is a mandatory realisation parameter.

At the beginning of developing the performance specification, the requirements of the requirement specification are analysed first (chapter 4 subsystem specification).

Also chapter 3 should be considered during the requirements analysis, in order to understand the client’s motivation, objectives and desires.

The OCA approach has no requirements to the structure of the performance specification.

Subsequent to it, the contractor has to prove that the solution specification meets all predefined functional requirements. For this purpose, the OCA approach provides the conformity matrix (see excel-template . CM).

In this matrix, a comparison of all the relevant requirements from the client's perspective regarding to the SSS (grey) and functionalities of a subsystem from the point of view of the contractor with respect to the specification is made (pink).

On the requirements side (gray), the within the requirement specification defined protagonists (stakeholder, user, subsystems) and types of approval get assigned to the requirements (core functionalities). Accordingly, on the pink performance side, the solution approaches are allocated to their corresponding requirements.

This procedure allows both, client and contractor, to directly compare requirement and solution specification.

Functionalities in the Realisation Concep

Actor Requirement Type of approval Reference

<Stakeholder> <Core functionality> Example: E/ M/ A/ W/ N <Core functionality Realisation Concept, page X>

<User> <Functionality> Example: E/ M/ A/ W/ N <Functionality PH, Realisation Concept, page X>

<Subsystem> <Functionality> Example: E/ M/ A/ W/ N <Functionality PH, Realisation Concept, page X>

Requirements from specification <SSS-Name>

The contractor should have achieved the following bullet points at this stage (end of sequence 6):

Clarity on the solution specification in consultation with the client

Documentation of the solution specification in consultation with the client

Documentation how the solution specification correlates with the requirements specification (conformity matrix)


OTS-Guideline, /66

6.7 Sequence 7: Field Test

Figure20: Application Guidance from system design to implementation, activities sequence 7

Field Test:

Proof of the request

conforming behaviour/

characteristics in terms of

the realised system

Sequence 7: Field Test¤ Realised and Supplied System

P Readiness for Acceptance

Readiness for

AcceptanceP

Test Scenarios:

Creation of all test

scenarios


OTS-Guideline, /66

Sequence 7: Field Test

Test Scenarios: ¤ Realised and Supplied System

Creation of all test scenarios P Readiness for Acceptance

Introduction to the Field Test

The field test analyses, if the realised subsystem, its communicative relations to other subsystems as well as its interaction with them applies to the requirement specification resp. solution specification.

For the field test, four test levels of the in sequence 3 introduced acceptance trial are suitable.

Level 1: Functional and behavioural test of the subsystem

All functional requirements, especially all specified use cases, for which performance or information of other subsystems is required, are tested.

Level 2: Test of every interface to other subsystems

Here, all protocol functions, activities and all types of data that are transported during communication via the respective interface are checked with help of a corresponding interface specification. This test should include a fault simulation.

Level 3: Functional and behavioural test of the subsystem in communicative connection to a test system

All functional requirements, especially all specified use cases, for which performance or information of other subsystems is required, are tested. However, communication partners are not the subsystems of the overall system, into which the to-be-tested subsystem shall get implemented, but a testsystem that provides necessary performance and information for this test.

Level 4: Test of the interaction with other new subsystems (system integration test) as well as already existing subsystems of the overall system

All functional requirements, especially all specified use cases, for which performance or information of other subsystems is required, are tested.

For level 1 to 3, the respective test object is to be tested independent from the rest of the system. This is the only way to observe an expected and predefined reaction without falsification due to the influence of other objects.

While being in operation, level 4 may only allow random samples. A selective simulation or direct observation is not possible.


OTS-Guideline, /66

Taking into account the available financial and human resources, the client has to define the scope of testing and its procedure already at the definition of the requirements specification and check the following test options and combinations:

Guarantee by the contractor

The client abstains from testing a requirement, because the procedure is economically not worthwhile for both sides. However, the contractor provides a guarantee for fulfilling this requirement.

Factory testing

The factory testing aims to prevent on-site development work by executing field test level 1 to 3 before delivery. Only successful factory testing results in delivery, installation and implementation of the subsystem. After successful accomplishment of the factory testing, the contractor declares in writing that all tests were conducted without any mistake and provides the documentation of the specific results of all tests. However, the factory acceptance does not replace level 4, the trial operation and the following acceptance.

Preliminary acceptance

During preliminary acceptance, test levels 1 to 4 are conducted by the contractor without attendance of the client. This helps to prepare trial operation and the final acceptance and conduct them effectively and without any risks. Therefore, the subsystem needs to be completely installed, integrated into the overall system and meet all requirements, including all supply- and configuration services. In case of missing or mistaken functionalities, the client may deny the preliminary acceptance.

By forestalling the acceptance, the client intends that trial operation and final acceptance can be conducted in one turn and without any shortcomings.

After successful accomplishment of the preliminary acceptance, the contractor declares in writing that all tests were conducted without any mistake and provides the documentation of the specific results of all tests. Furthermore, he declares the readiness for the trial operation. Content wise, the preliminary acceptance matches the final acceptance, i.e. all types of tests and acceptance need to be made.

Trial operation

Every client has to check for himself, if he wants to combine test level 4 with the trial operation.

Creating Test Scenarios

The user “tester” (client or an experienced representative) has to define certain test scenarios for all test levels regarding acceptance. If this also needs to be done for the evaluation is within the decision of the client.

All test scenarios are based on requirement and solution specifications, meaning that these documents have to be evaluated regarding testable requirements and to be classified in test and acceptance types, introduced in sequence 3.

Instead of the specifications, the conformity matrix is also applicable for the creation of test scenarios.

It is highly recommended to use the following approach for the documentation of the test scenarios; however, there are no requirements within the OCA approach for the structure of the test specifications.

First, the to-be-tested functionalities have to be classified in order to estimate their criticality or their corresponding defects. There are three different categories:


OTS-Guideline, /66

A = critical: Essential functionality for the ongoing operation; the elimination of a defect has the highest priority

B = normal: Defect elimination has average priority, because it can be temporarily operated without the functionality

C = less important: Functionality is not essential for operation and therefore the elimination of the defect has low priority

Every classification needs to be justified as exemplarily shown:

Functionality Classification Justification

automatic traffic programme selection

A Primary operating component

Not-automatic traffic programme selection

B Subordinate operating component

Emergency control B Subordinate operating component

… … …

Based on these classifications, the test scenarios subordinated to the functionalities are classified. They get either the same classification as the related system or a lower one (in case less important parts are tested).

The documentation of a test scenario consists of the introducing part “requirements” and the actual test run. Within the requirements, it is briefly described under with circumstances the test is to be made.

In greater detail, the test run consists of consecutively numbered instructions, after which expected results can be added. If user interfaces (GUI) are tested, a screenshot is very useful for the better orientation.

A description may look like this:

<Functionality> <Test scenario-short title> <Classification>

Circumstances

Test run

Step 1

…

Step n

With the help of an additional assignment of an unique and immutable identification number to each test scenario, a reference could connect to a bug tracking system.

The criteria for a successful test run have to be previously agreed upon and documented in the test specification. The same applies for repeated tests between client and contractor.


OTS-Guideline, /66

Sequence 7: Field Test

Field Test: ¤ Realised and Supplied System

Proof of the request conforming

behaviour/characteristics in terms of the realised

system P Readiness for Acceptance

The user “tester” (client or an experienced representative) assigns the test scenarios, described in the test specification, to test level 1 to 4. The test levels and the related scenarios are run for every single subsystem.

Only when a test stage is successfully carried out and the corresponding test scenarios were tested free of defects, the next test level can be run. Exceptions are the test levels 1 and 2, which may be performed independently.

For every test level, there is a checklist with all obligatory test scenarios. Within this checklist, every performed test run is documented with a time stamp, the authorised user and the result. Potentially occurred defects are also mentioned. If, for example, a bug tracking system is used to support the test run, found defects can be gathered there and be pursued further (with help of an identification number of the test scenario).

In case the subsystem was successfully tested and all defects were eliminated, the checklists of all test levels are added to the test specification for documentation purposes. Now, the contractor may notify the client of the readiness for acceptance of the subsystem.

Client and contractor should have achieved the following bullet points at this stage (end of sequence 7):

Clarity on all test cases

Detailed documentation of all test cases

Execution of all test cases

Remedy of possibly identified deficiencies and signalling the readiness for acceptance


OTS-Guideline, /66

6.8 Sequence 8: Trial Operation


Sequence 8: Trial Operation

Trial Operation: ¤ Realised and Supplied System

Proof that the to-be-accepted system meets the

requirements of the real life and survives a trial

operation without errors P Accepted System

A trial operation shall provide proof that the to-be-accepted subsystem meets the requirements of real life. Therefore, the client decides on how long the period of the trial operation is. Client and contractor have to agree to terms, in what circumstances the trial operation has to be abandoned, repeated or paused.

Before starting the trial, all trainings have to be completed, so that every user can operate and maintain independently. They have to be qualified, to test the appropriate use and ergonomics of the subsystem in real life conditions.

A successful trial operation is a mandatory requirement for the acceptance.

Acceptance:

Formal confirmation of the

contractual execution /

delivery

Sequence 8: Trial Operation¤ Readiness for Acceptance

P Accepted System

Trial Operation:

Proof that the to-be-

accepted system meets

the requirements of real

life and survives a trial

operation without errors.

Accepted SystemP


OTS-Guideline, /66

Sequence 8: Trial Operation

Acceptance: ¤ Readiness for Acceptance

Formal confirmation of the contractual execution /

delivery P Accepted System

The acceptance is the confirmation of the contractor that the deliverable subsystem meets its requirements.

That means a fully repetition of the test sequences 1 to 4 (approval tests) in presence of the client. The latter also checks its remaining requirements categorized by types of test and acceptance (Evaluation [E] and measurement or allowance [M]).

The acceptance has the following effects:

The fee is payable and shall bear interest.

The risk of accidental deterioration passes to the client.

The client loses certain rights with respect to such defects he knows at acceptance, but does not reserve.

The burden of proving the existence of a defect omits to the client (burden of proof), unless a reservation has been explained during the acceptance.

The statute of limitations for certain claims for defects begins after completion of acceptance.

The client loses his right on contract penalties, unless a reservation has been explained during the acceptance.

The work contract cannot be terminated anymore.

Generally, the contractor has to prepare the acceptance. Therefore, he has to provide all test systems and the required personnel other than the client’s staff resp. the client’s authorised expert.

The acceptance results are documented by the client in an acceptance protocol. There is no template provided by the OCA approach. In this protocol, reservations because of defects or contract penalties are mentioned. Also objections of the contractor can be mentioned. Every party gets a copy.

For possibly occurring defects, the client sets a deadline for the removal. Until then, the acceptance may be denied.

Client and contractor should have achieved the following bullet points at this stage (end of sequence 8):

Providing evidence that the to-be-accepted system meets the requirements for the real life

Acceptance of the system by the formal confirmation of the contractual execution / delivery


OTS-Guideline, /66

PART IV OUTLOOK

7. Qualification and quality

The OTS-Guideline is not a textbook

The OTS-Guideline is not a textbook for self-study, but rather a reference book that applies case-by-case fundamental considerations for system design in relationship with the OTS concept. Therefore not all possible cases can be identified and considered.

However, any potential user for himself must answer the question how he can fulfil the sophisticated system modelling tasks.

The authors are convinced that in generally cases, at the initial application, a moderation would be useful.

OTS maturity levels: build skills in stages

Not everyone who is faced with a design challenge will be able to fulfil all requirements imposed on him. Experience is required in order to deal differentiated and evaluative with the various aspects of the system-designing. Gaining expert knowledge is part of this process as well.

The OTS process itself, which is to be established and chaired by the OCA, requires qualified contributors. In meaningful intervals, the guidelines, which are made by the OCA must be critically examined.

OTS maturity levels are currently: initial, supported, defined, lived, optimized.

The OTS-Guideline refers to the milestones OCIT®/OTS 1 and 2 as part of the OTS -processes and describes the required knowledge that authorities and system operators need to acquire in order to achieve the level defined. This maturity level is currently sufficient. It means that authorities and operators have achieved sufficient qualifications for a specific OTS scenario in order to specify the particular requirements of the communicative aspects of a vendor mixture precisely and understandable for both contracting parties. The OTS maturity level supported means that authorities or system operators should have the basic knowledge to understand problems resulting from a vendor mix. They need support for specification and evaluation, which can be done by a consultant.

But the necessary qualification also depends on the task and the associated complexity. It is crucial that the system architect can only refer to available communication standards and rely on those or whether he has to specify requirements, that lead to activities on the communication level. Because of the complexity of different vendor mix situations, the OTS-Guideline includes different OTS scenarios.

Quality of a system specification

An increasing qualification of a system architect improves the quality of the designed system, which can be influenced by various compromises.

The specification of a system is subject of many boundary conditions that are likely to differ widely in different localities. The desire for an optimal system specification leads therefore in a compromise as local optimum.

Optimal solutions with an extensive catalogue of requirements, almost inevitably lead to vendor mixture. On the one hand, additional benefits sometimes create more problems in terms of integration due to the interaction of different manufacturer components in an overall system.

Principally, the system architect has the task to specify a system solution, with which specific design problems can be solved. I.e. how the system can be designed to solve a specific problem and the system land scape is open for the future as well. The specification is the


OTS-Guideline, /66

result of a locally organized problem-solving process that starts with the exact problem description and ends with the specification and a tender that should solve the problem.

The grade or quality of the problem solution depends on the quality of its institutional organization, as well on the quality of the personnel that are involved.

The entire process of finding solutions is reflected in the specification of an optimal system solution. The OTS-Guideline focuses situations, basically in the process of fulfilling a design task that focusses a long-term perspective of the design of a system land scape.

Gliederung des Dokuments - oca-ev.info · the so called OTS-initiative (Open traffic systems...

Documents

Transcript of Gliederung des Dokuments - oca-ev.info · the so called OTS-initiative (Open traffic systems...