D2.4 Quality Management_FD0.1

Embed Size (px)

Citation preview

  • 7/30/2019 D2.4 Quality Management_FD0.1

    1/23

    D 2.4

    Quality ManagementConcept

    Project acronym: EDC-11145 EUROROADS/28646Deliverable: D2.4Nature: PublicAuthor: Thilo Kaufmann, Thomas WiltschkoDate: 06-02-20Version: FD 0.1

  • 7/30/2019 D2.4 Quality Management_FD0.1

    2/23

  • 7/30/2019 D2.4 Quality Management_FD0.1

    3/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 3 (23)

    1 Introduction

    1.1 Aims and scopeIn EuroRoadS report D2.4 a quality management concept for information processesis to be formulated. The concept of report D2.4 is the basis for quality management inthe EuroRoadS-demonstrator of work package 7.

    The report and its proposed quality management concept only deals with the qualitymanagement of road data and their data providing processes. A quality managementof the project and its workflow is not subject of this report.

    1.2 Methodology and sequenceThe EuroRoadS report D2.4 Quality Management Concept is structured as follows:First the mindset of quality management in general according ISO 9000-series andPDCA-cycle is presented.

    In chapter 3 the general phases of quality management (Plan, Do, Check, Act) aresubdivided into different tasks for quality management of road data processing. Foreach of these tasks corresponding methods are suggested. The implementation ofthese tasks and methods within EuroRoadS processes is illustrated exemplarily.

    2 Quality management basics

    2.1 ISO 9000-seriesAccording to EN ISO 9000 quality management is defined as coordinated activitiesto direct and control an organization with regard to quality. Direction and control withregard to quality generally includes establishment of the quality policy and qualityobjectives, quality planning, quality control, quality assurance and qualityimprovement:

    quality planning is focused on setting quality objectives and specifying necessaryoperational processes and related resources to fulfil the quality objectives

    quality control is focused on fulfilling quality requirements

    quality assurance is focused on providing confidence that quality requirementswill be fulfilled

    quality improvement is focused on increasing the ability to fulfil the qualityrequirements

  • 7/30/2019 D2.4 Quality Management_FD0.1

    4/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 4 (23)

    2.2 PDCA-cycle

    An important mindset of quality management is the so-called PDCA-cycle (Fig. 1).This cycle including the four components Plan, Do, Check and Act (PDCA), wasoriginally conceived by Walter Shewhart in the 1930`s, and later adopted by W.Edward Deming. The model provides in general a framework for the improvement ofa process or system and is an iterative four-step quality strategy (cf. Deming 1982).

    implementationof processes

    take actions to the outcomefor necessary improve-ment (e.g. improve,standardize)

    monitor andevaluate processesand results againstobjectives and specifications

    establish objectives andprocesses necessary to

    deliver results inaccordance to

    specificationPlan

    DoCheck

    Act

    implementationof processes

    take actions to the outcomefor necessary improve-ment (e.g. improve,standardize)

    monitor andevaluate processesand results againstobjectives and specifications

    establish objectives andprocesses necessary to

    deliver results inaccordance to

    specificationPlan

    DoCheck

    Act Plan

    DoCheck

    Act Plan

    DoCheck

    Act

    Fig. 1: PDCA-cycle

    The cycle begins with investigation of the present situation, in order to formulate aplan for improvement (Plan). In the following the planned processes are realised (Do)

    and evaluated whether the desired improvement was obtained (Check). In positivecase the measures become standard and/or can be reworked in a new iteration (Act).Herein a starting point for constant improvement of quality and the linked work with itcan be seen.

  • 7/30/2019 D2.4 Quality Management_FD0.1

    5/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 5 (23)

    3 Quality management for EuroRoadSThe described general mindset of PDCA-cycle is adapted for special issues of roaddata processing. Therefore the general phases of quality management (Plan, Do,Check, Act) are subdivided into different tasks for quality management of road dataprocessing. For each of these tasks (e.g. detection sources of error) correspondingmethods are developed and/or adapted (e.g. probabilistic model, cause and effectdiagram) In Tab. 1 a compilation of methods and their corresponding tasks isillustrated.

    Tab. 1: Compilation of methods and tasks for EuroRoadS quality management

    According to this structure the methods and their application within EuroRoadSquality management concept are explained in the following.

    methods:

    tasks:

    qualitymodel

    probabilisticmodel

    causeand

    effectdiagram

    failuremode and

    effectsanalysis

    qualityassurancemeasures

    evaluationmethods

    metadatacatalogue

    specification qualityrequirements

    X

    detection sources oferror

    X X X X X

    development of qualityassurance measures

    X X X X XPlan

    verification of theefficiency of qualityassurance measures

    X X X

    Do

    implementation ofquality assurancemeasures

    X

    determination ofinformation quality

    X X

    Checkproof efficiency of

    quality assurancemeasures

    X X X X

    documentation ofquality

    X X

    Act

    documentation ofprocesses

    X X X

  • 7/30/2019 D2.4 Quality Management_FD0.1

    6/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 6 (23)

    3.1 Quality modelThe first task of the phase Planis specification of quality requirements, which have to

    be formulated individually for each use case. Therefore a threshold value for dataquality result has to be used to determine how well a dataset meets the criteria setforth in user requirements.

    So each data supplier can formulate its own and individual quality objective for itsdatabase by specifying quality requirements. As well as a data user can specifyquality requirement for the service.

    EuroRoadS quality model, which is specified for a uniform and objective descriptionof quality of all data and data types within the entire information chain (EuroRoadSreport D2.2.) can be used for specification of quality requirements. The EuroRoadSquality model is structured as follows:

    formulated

    by

    Qualitycharacteristic

    Qualitts-parameter

    Qualityparameter

    value

    Qualitts-parameterQuality

    parameter

    Qualityphenomenon

    describe

    makeconcret

    quantify

    determine Qualityevaluation

    method

    Qualitts-forderungQuality

    requirement

    fixeds

    etofinherent

    quality

    characteristics

    correctness

    consistency

    completeness

    accuracy

    availability

    up-to-dateness

    formulated

    by

    Qualitycharacteristic

    Qualitycharacteristic

    Qualitts-parameter

    Qualityparameter

    value

    Qualitts-parameter

    Qualityparameter

    value

    Qualitts-parameterQuality

    parameter

    Qualityphenomenon

    describe

    makeconcret

    quantify

    determine Qualityevaluation

    method

    Qualityevaluation

    method

    Qualitts-forderungQuality

    requirement

    Qualitts-forderungQuality

    requirement

    fixeds

    etofinherent

    quality

    characteristics

    correctness

    consistency

    completeness

    accuracy

    availability

    up-to-dateness

    fixeds

    etofinherent

    quality

    characteristics

    correctness

    consistency

    completeness

    correctness

    consistency

    completeness

    accuracy

    availability

    up-to-dateness

    availability

    up-to-dateness

    Fig. 2: Structure of EuroRoadS quality model

    A quality requirement, which means a mandatory level of quality, is formulated by aquality parameter value(e.g. 98%). This numerical value, which is to be determined

    by quality evaluation method (cf. chapter 3.6), is the quantification of a qualityparameter (e.g. rate of omission). These parameters make concrete qualitycharacteristics(e.g. completeness).

  • 7/30/2019 D2.4 Quality Management_FD0.1

    7/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 7 (23)

    3.2 Probabilistic modelThe first step for detecting sources of errors within processes can be documentation

    of information processes. This can be done by the graphical part of the probabilisticmodel (cf. EuroRoadS report D2.3). This intuitive understandable information flowchart consists in general of input data, which are transformed by an application tooutput data:

    applicationapplicationinputdata

    inputdata

    outputdata

    outputdataapplication

    applicationinputdata

    inputdata

    outputdata

    outputdata

    Fig. 3: Basic elements of information flow chart

    An application can be:

    AND-linkage logical average for two or more inputinformation &

    OR-linkage will be used, if at least one input isnecessary for the generation of the outputinformation

    1

    single branching divides the information flow into two paths independence of a query no

    yes

    single check divides the information flow into two paths independence if a requirement is fulfilled or

    not fulfilled

    yes

    no

    check

    yes

    no

    check

    exclusive OR-linkages is used for the connection of disjunctivesystem states as a result of a singlebranching or single check

    =1

    Based on the documentation of processes error of sources can be detected asillustrated in the examples (cf. chapter 4.1.1 and 4.1.2). Additionally qualityassurance measures (e.g. checking and editing) can be developed and theirefficiency can be verified by using the analytical part of the probabilistic model, like itis illustrated in Fig. 4. That means that effects of planned quality assurance measurescan be analysed in a simulation before they will be integrated costly in real

    processes. The computing procedure for verification of efficiency is described indetail and illustrated with examples in EuroRoadS-Report D2.3.

    matching &merging

    &

    road network

    speed traffic sign

    road network &speed traffic sign

    storage

    &

    road network & speedtraffic sign

    (EuroRoadS - shop)

    CM = AVAV = 1/AV

    [ ]984.0,993.0,0.1=ERI

    AV

    Map

    CM

    Trans

    AV

    Map

    AV

    Trans

    II

    II

    =

    = /1[ ]98.0,99.0,999.0=RNI

    [ ]95.0,98.0,999.0=TSI

    [ ]931.0,970.0,998.0=MapI

    Quality assurance procedures

    checking and editing

    ...

    matching &merging

    &

    matching &merging

    &

    matching &merging

    &

    road networkroad network

    speed traffic signspeed traffic sign

    road network &speed traffic signroad network &

    speed traffic signstorage

    &

    storage

    &

    storage

    &

    road network & speedtraffic sign

    (EuroRoadS - shop)

    road network & speedtraffic sign

    (EuroRoadS - shop)

    CM = AVAV = 1/AV

    [ ]984.0,993.0,0.1=ERI

    AV

    Map

    CM

    Trans

    AV

    Map

    AV

    Trans

    II

    II

    =

    = /1[ ]98.0,99.0,999.0=RNI

    [ ]95.0,98.0,999.0=TSI

    [ ]931.0,970.0,998.0=MapI

    Quality assurance procedures

    checking and editing

    ...

    Fig. 4: Verification of efficiency of quality assurance measures

    by using the analytical part of the probabilistic model

  • 7/30/2019 D2.4 Quality Management_FD0.1

    8/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 8 (23)

    3.3 Cause and effect diagramThe Ishikawa`s cause and effect diagram is a graphical method for finding the mostlikely causes for an undesired effect. The method was at first used by Kaoru Ishikawa

    in the 1960s. Because of its shape, it is also known as the fishbone diagram. Thecause and effect diagram is a method used in a root cause analysis.

    The diagram has to include a horizontal line from left to right side. At the right side ofthe line the effect is to be labeled. Starting from the horizontal line four to six shortdiagonal lines are to be drawn in direction left upper and left lower corner of thepaper. These are the main bones of the diagram and the categories of main causesare to be labeled. For example, a business may use: material, manpower, method,and machine (the 4 M's). For this main cause categories more detailed categoriescan be added.

    Fig. 5: Cause and effect diagram adapted to the issues of road data processing

    This general method of quality management can be adapted for finding quality lackswithin data providing processes: The quality within the data providing processesgenerally depends of input data (`material`), operator (`manpower`), software(`method`) and hardware (`machine`). These general causes were identified by theanalysis of exemplary providing processes (c.f. EuroRoadS report D2.3). In thefollowing these four main causes are described:

    Data:It is a clear fact, that quality of input data is essential for the processes andfor quality of resulting output data.

    Operator: If it is a manual process (e.g. manual digitising) then human errors caninfluence the quality of data provision. Thus it is a crucial point for quality of

    operators, that this specialised staff has continuously advancing training for theirtasks.

    Hardwarecan also have an impact to quality: Hardware failures and errors can bereduced by use of high-grade hardware, and expert implementation, andmaintenance.

    Software:When a software algorithm is very complex and contains fuzziness indata processing (e.g. raster-vector-conversion, automatic error detection, orcoordinate thinning) then the software can have an important influence on dataquality. Thus use of professional and debugged software and softwarecomponents can be important to reduce failures and errors.

    In chapter 3.5 these quality assurance measures are described more detailed.

  • 7/30/2019 D2.4 Quality Management_FD0.1

    9/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 9 (23)

    3.4 FMEAFailure Mode and Effects Analysis (FMEA) is a method, originally developed forsystems engineering, used to examine potential failures in products or processes. It

    is used to evaluate the priorities of risks, and helps to determine remedial actions tominimize the risk of the failure. It is used in many formal quality systems such asQS 9000 or ISO/TS 16949.

    The basic process is to take a description of parts of a system, and list consequencesif each part fails. In most formal systems the consequences are then evaluated bythree criteria and associated risk indices:

    severity (S),

    likelihood of occurrence (O) (Note: This is also often known as probability (P))

    inability of controls to detect it (D)

    Each index ranges from 1 (lowest risk) to 10 (highest risk). The overall risk of eachfailure is called Risk Priority Number (RPN) and the product of Severity (S),Occurrence (O), and Detection (D) rankings: RPN = S O D. The RPN (rangingfrom 1 to 1000) is used to prioritize all potential failures to decide upon actionsleading to reduce the risk, usually by reducing likelihood of occurrence and improvingcontrols for detecting the failure.

    Fig. 6: Failure mode and effects analysis

    For these potential failures quality assurance measures are necessary which aredescribed in detail in chapter 3.5.

  • 7/30/2019 D2.4 Quality Management_FD0.1

    10/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 10 (23)

    3.5 Quality assurance measuresThe main objective of quality assurance measures in information processes is to fulfil

    a required quality level. By using described probabilistic model, cause and effectdiagram, and/or FMEA there are firstly to analyse existing processes and to detectexisting quality gaps within these processes. Based on these facts adequatemeasures are to be developed and to be implemented to assure quality:

    Error avoidance in sourcing means that probability of erroneous data can bereduced by using a better quality of sources. The quality of used software, hardwareand data sources can be assured by different measures, e.g.:

    - from suppliers a defined quality level is required

    - used hardware, software and data have to be checked in regular intervals.

    - quality influence of human resources (operator) can be assured by continuouslyadvanced training.

    Error control in processingmeans that within a process erroneous data has to beidentified and reworked. The quality within processes can be assured by differentmeasures, e.g.:

    - user guidelines are necessary, describing how errors will be identified andreworked.

    Within the following list only some examples of quality assurance measures aredescribed. These are dependent of each individual case.

  • 7/30/2019 D2.4 Quality Management_FD0.1

    11/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 11 (23)

    main influence process

    (examples) inputdata

    operator hardware softwarequality assurance measure (examples)

    X Scanner with required resolution (dpi), colour depth, etc. has to b

    X Scanner has to be checked in regular intervals

    X User guideline for scanning has to be documented

    X Input Data with required scale has to be used

    scanning

    X Software for postprocessing (e.g. rubbersheeting) has to be use

    X Operator has to be continuously advanced training

    X User guideline for digitising has to be documented

    X Input data with required quality is to source

    manualdigitising

    X Monitor with required resolution has to be used

    semi-automaticdigitising

    XTracing modus has to be used, which inform the operator when data are found.

    automaticdigitising

    X

    Errors of raster-vector-conversion (e.g. round off edge, junction bstubble, junction shifting, island) has to be identified and has to bby editing. For typical conversion errors and their correction a ushas to be documented.

    topology

    generation

    X

    Blunders of topology generation (e.g. closed polygons, joined neto be identified:

    - topology blunders in road network (e.g. turn offs in road networflow in street network) can be identified by test routing.

    - explicitly encoded topological characteristics (e.g. closed polygdataset can be identified by automatically generated comparisontopological specification.

    Based on identification has to be corrected by editing. For typicaerrors and their correction a user guideline has to be documente

    Tab. 2: Examples for quality assurance measures

  • 7/30/2019 D2.4 Quality Management_FD0.1

    12/23

  • 7/30/2019 D2.4 Quality Management_FD0.1

    13/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 13 (23)

    3.7 Documentation of quality within metadataFinally the quality improvement has to be standardised; i.e. processes and evaluated

    data quality have to be documented. Based on this quality documentation a newiteration of PDCA-cycle can be started.

    For a quality documentation is necessary, that the EuroRoadS quality model is partof the metadata catalogue (EuroRoadS report D6.8), which is integrated in theEuroRoadS exchange format. In this way the quality description within the metadatacan be transferred within the whole information chain and can be edited if necessary(cf. Fig. 8). Quality assurance measures can be accomplished to fulfil required dataquality based on such a transferable documentation.

    quality management

    quality management

    quality management

    quality management

    quality management

    data processing

    EuroRoadSinterface applications

    data

    metadata

    e.g.: informationretrieval system

    e.g.: map-basedADAS

    data

    metadata

    data

    metadata

    dataprovider

    contentprovider

    informationprovider

    serviceprovider

    quality management

    quality management

    quality management

    quality management

    quality management

    data processing

    EuroRoadSinterface applications

    data

    metadata

    e.g.: informationretrieval system

    e.g.: map-basedADAS

    data

    metadata

    data

    metadata

    dataprovider

    contentprovider

    informationprovider

    serviceprovider

    Fig. 8: Quality documentation in metadata as basis forquality management within the whole information chain

    In the EuroRoadS metadata catalogue core elements and other important elementsof ISO 19115 are included. Furthermore the catalogue contains extended elements,which are important for road databases, their quality description and theirinternational application. The metadata catalogue is integrated into the exchangeformat (EuroRoadS report D6.11) as well as parts of it into the metadata server(EuroRoadS report D7.2).

    ISO 19115EuroRoadS MetadataCatalogue

    SubsetMetadata Server

    Data

    MetadataExchange Format

    Quality

    ISO 19115EuroRoadS MetadataCatalogue

    SubsetMetadata Server

    Data

    Metadata

    Data

    MetadataExchange Format

    Quality

    Fig. 9: Connection of EuroRoadS metadata catalogue and ISO 19115as well as integration into metadata server and exchange format

  • 7/30/2019 D2.4 Quality Management_FD0.1

    14/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 14 (23)

    The EuroRoadS exchange format is realised by the Swedish road administrationVgverket (WIKSTRM 2006). A part of quality documentation within this XML/GML-based exchange format is illustrated in Fig. 10.

    Fig. 10: Part of quality documentation in EuroRoadS exchange format(Source: WIKSTRM 2006)

    Furthermore parts of the metadata catalogue are implemented into EuroRoadSmetadata server. By using this server a user can achieve quality information beforesourcing data and can check if data fulfil his quality requirements. Parts of qualitydocumentation in the metadata server is illustrated in Fig. 11.

    Fig. 11: Part of quality documentation in the EuroRoadS metadata server(Source: DDS/PTV 2006)

  • 7/30/2019 D2.4 Quality Management_FD0.1

    15/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 15 (23)

    4 Examples of quality management in demonstration

    4.1 Modelling of information processes and their impact onqualityIn this chapter examples of information processes and their impact on quality areillustrated. The examples are modelled, described and interpreted in cooperation withEuroRoadS-project partners Bundesamt fr Eichwesen und Vermessung BEV(Austria) and Lantmteriet (Sweden).

    4.1.1 Updating processes in (Austria)

    An example for modelling of information processes by using the graphical part of the

    probabilistic model is illustrated by the following updating processes in BEV (Austria).The two scenarios the periodical and event-driven update is analysed withrespect to their effects to the quality parameter values of rate of up-to-dateness.

    4.1.1.1 Periodical UpdatePer year 1/7 of the area of Austria is updated, i.e. there is a periodical update with atotal duration of seven years which is mainly carried out for cartographic purposes.That means that road category and geometry is kept up-to-date also by means offield work. This is an additional check on completeness. Meanwhile steady data fromphotogrammetric evaluation are aggregated, nowadays only for lower level road-network.

    system component: branching: area to be topographically reworkedsystem component: merging

    existing road- data

    lower-order road-datafrom photogrammetry

    (continiouslyaggregated)

    & merged dataarea to be

    topographicallyreworked? no

    yes

    not reworked6/7

    data plannedto be reworked

    1/7(1)

    (2)

    system component: branching: area to be topographically reworkedsystem component: branching: area to be topographically reworkedsystem component: mergingsystem component: merging

    existing road- dataexisting road- data

    lower-order road-datafrom photogrammetry

    (continiouslyaggregated)

    lower-order road-datafrom photogrammetry

    (continiouslyaggregated)

    && merged dataarea to be

    topographicallyreworked? no

    yesarea to be

    topographicallyreworked? no

    yesarea to be

    topographicallyreworked? no

    yesarea to be

    topographicallyreworked? no

    yes

    not reworked6/7

    data plannedto be reworked

    1/7(1)

    (2)

    Fig. 12: Modelling of first part of periodical update processes of BEV

    The first part of periodical update processes as illustrated in Fig. 12 can bedescribed as follows: Firstly existing road-data are continuously aggregated, lower-order road-data from photogrammetry are merged. Then information flow is dividedinto two paths, depending whether the areahas to be reworked topographically.

    system component: check of up-to-dateness and reworking

    check for up-to-dateness

    no

    yes

    UP

    reworking ofattributes and

    geometry

    &

    updated data

    data up to date

    system component: merging

    topographicallyreworked

    1/7=1

    system component: merging

    =1 updatedroad-data

    (2)

    (1)

    system component: check of up-to-dateness and reworking

    check for up-to-dateness

    no

    yes

    UP

    reworking ofattributes and

    geometry

    &

    updated data

    data up to date

    system component: check of up-to-dateness and reworkingsystem component: check of up-to-dateness and reworking

    check for up-to-dateness

    no

    yes

    UP check for up-to-dateness

    no

    yescheck for up-to-

    datenessno

    yescheck for up-to-

    datenessno

    yescheck for up-to-

    datenessno

    yes

    UPUP

    reworking ofattributes and

    geometry

    &

    reworking ofattributes and

    geometry

    &

    reworking ofattributes and

    geometry

    &

    updated dataupdated data

    data up to datedata up to date

    system component: mergingsystem component: merging

    topographicallyreworked

    1/7

    topographicallyreworked

    1/7=1=1

    system component: mergingsystem component: merging

    =1=1 updatedroad-dataupdated

    road-data

    (2)

    (1)

    Fig. 13: Modelling of second part of periodical update processes of BEV

  • 7/30/2019 D2.4 Quality Management_FD0.1

    16/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 16 (23)

    The second part of periodical update processes as illustrated in Fig. 13 can bedescribed as follows: The data of the area to be reworked topographically is checkedfor up-to-dateness. To find out whether the data are up-to-date, orthophotos andname gazetteers are compared for changes. In case of changes, these are mapped

    in outdoor working. The indoor reworking process afterwards as one consequenceaffects the road data. Then the data that is up-to-date and the data that was updatedare merged. Finally the topographically reworked data and the data, that was notreworked are merged. The updated road-data are the result.

    00

    rate of up-to-dateness

    0201 03

    90%

    95%

    99% 1stpart

    04 05 06 07

    80%

    85%

    75%

    65%

    70%

    2ndpart3rdpart

    4thpart5thpart

    6thpart7thpart

    averageofallparts

    time00

    rate of up-to-dateness

    0201 03

    90%

    95%

    99% 1stpart

    04 05 06 07

    80%

    85%

    75%

    65%

    70%

    2ndpart3rdpart

    4thpart5thpart

    6thpart7thpart

    averageofallparts

    time

    Fig. 14: Analysis of periodical update regarding up-to-dateness

    In Fig. 14 it is assumed exemplarily that there is an average rate of change of 5 %in each year. It is also exemplarily assumed that a part of the area has a rate of up-to-dateness of approx. 99% at the date of last update (year 2000 for first part, year2001 for second part, etc. ). Per year 1/7 of the area is updated, i.e. each of theseven parts of the whole area are updated all seven years. Thus the rate of up-to-

    dateness for each part falls from approx. 99% to 65% in seven years. Consequentlythe average rate of up-to-dateness of all parts of the area is between approx. 85% to80% each year.

    4.1.1.2 Event-driven updateFor the main roads (Autobahn, Schnellstrae, Landesstrae) an event-drivenprocess called "Laufende Aktualisierung" (ongoing updating) is carried out. BEV getsthe information on building activities from contractors and acts upon it as soon aspossible. This second process runs independently from the former. It is not formallysynchronised with the first, so it is open, whether it runs before or after this process.But it may affect the same roads.

    System component:event:check for building activity on main roads

    check for building activity onmain roads

    no

    yes

    roads to be updated

    unchanged roads

    System component: updating data with GPS

    roads to be updated updated roadsupdating with GPS

    &

    GPS

    (1)

    (2)

    System component:event:check for building activity on main roads

    check for building activity onmain roads

    no

    yes

    check for building activity onmain roads

    no

    yes

    check for building activity onmain roads

    no

    yes

    roads to be updatedroads to be updated

    unchanged roadsunchanged roads

    System component: updating data with GPS

    roads to be updatedroads to be updated updated roadsupdated roadsupdating with GPS

    &

    updating with GPS

    &

    updating with GPS

    &

    GPSGPS

    (1)(1)

    (2)(2)

    Fig. 15: Modelling of first part of event-driven update processes of BEV

  • 7/30/2019 D2.4 Quality Management_FD0.1

    17/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 17 (23)

    The first step of process as illustrated in Fig. 15 is the check of building activity onmain roads. It is more or less a query to real world and not to real data. Then theselected roads are updated with the system component GPS.

    system component: merging

    =1updated

    road-data

    system component: usage

    up-to-dateness

    usage ofroad data

    &road data

    (1)

    (2)system component: mergingsystem component: merging

    =1=1updated

    road-dataupdated

    road-data

    system component: usagesystem component: usage

    up-to-dateness

    usage ofroad data

    &

    usage ofroad data

    &

    usage ofroad data

    &road data

    (1)(1)

    (2)(2)

    Fig. 16: Modelling of second part of event-driven update processes of BEV

    The following process as illustrated in Fig. 16 can be described as follows: theupdated roads and the unchanged roads are merged. Here topological checks byGIS, and database checks for the integrity of attributes are applied. Finally influenceof time and involved downgrade of up-to-dateness of data is modelled by thetransition symbol.

    time

    rate of

    up-to-dateness

    01

    98%

    00

    99%

    time

    rate of

    up-to-dateness

    01

    98%

    00

    99%

    Fig. 17: Analysis of event-driven update regarding up-to-dateness

    In Fig. 17 it is assumed exemplarily that the whole database has a rate of up-to-dateness of approx. 99% at the date of last update. The falling of rate of up-to-dateness is depending on the time delay between building activities on main roads,and date of update in the database. Consequently the rate of up-to-dateness byevent driven update could be closely to 99%. It can be presumed that the event-driven update delivers a higher quality of up-to-dateness. By implementation of a wellorganized workflow a further increase of quality (here: up-to-dateness) can berealized.

    4.1.2 Checks and reworking (Sweden)

    The modelled procedures of checking and reworking are examples from Lantmteriet(Sweden). In the first step of updating process the basic data and the additional newdata are geometrically matched together. After that matching process different qualityimprovements are effected, like geometry and topology checks, and reworking.

    4.1.2.1 Geometry check and reworkingIt is not possible to see whether additional new data are a changed road or a newroad. Thus the following geometry check and reworking are done (cf. Fig. 18): If a

    change is inside the buffer zone, it is decided that it is the same road, so the updating

  • 7/30/2019 D2.4 Quality Management_FD0.1

    18/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 18 (23)

    can be done automatically. If it is outside the buffer zone, it has to be decidedwhether a road has changed or whether it is a new road.

    Check ifgeometry isinside buffer

    zone no

    yes

    Q

    Changegeometry

    automatically

    Changegeometrymanually

    Check thegeometrymanually

    &

    =1

    Datageometricallychecked and

    reworked

    Specification

    Geometricallymatched data

    Check ifgeometry isinside buffer

    zone no

    yes

    Q

    Check ifgeometry isinside buffer

    zone no

    yesCheck ifgeometry isinside buffer

    zone no

    yesCheck ifgeometry isinside buffer

    zone no

    yesCheck ifgeometry isinside buffer

    zone no

    yes

    QQ

    Changegeometry

    automatically

    Changegeometry

    automatically

    Changegeometrymanually

    Changegeometrymanually

    Check thegeometrymanually

    &

    Check thegeometrymanually

    &

    Check thegeometrymanually

    &

    =1=1

    Datageometricallychecked and

    reworked

    Datageometricallychecked and

    reworked

    SpecificationSpecification

    Geometricallymatched dataGeometricallymatched data

    Fig. 18: Modelling of geometry check and reworking

    By using this quality assurance method the following quality parameter value can beupgraded:

    If geometry of a road is changed, thegeometric correctnessis upgraded. To evaluatethis quality improvement it is assumed, that after geometrical reworking, geometriccorrectness value is approx. 99%. If exemplarily 2 km from 100 km road are changedgeometrically, the geometric correctness is upgraded from approx. 97% to 99%.

    If a new road is added, then the completenessis upgraded.To evaluate this qualityimprovement it is assumed that after adding of new roads the completeness value isapprox. 99%. If exemplarily to an existing database, including 100 km road, 1 kmnew road is added, the correctness is upgraded from approx. 98% to 99%.

    4.1.2.2 Topology check and reworking

    The topology check today has the aim to find gaps and overshoots. In case of aminor error within a buffer zone, the error can automatically be corrected. If it isoutside the buffer zone, it is not sure that it is an error, therefore someone has tocheck it manually and, if necessary, also correct it.

    =1

    Changegeometry

    automatically

    Datatopologically

    checked

    Check topologymanually

    &

    Changegeometrymanually

    Datageometrically

    and codedcorrectly

    Check if inbuffer zone

    no

    yes

    Q

    Topology errorcorrected by

    changinggeometry

    =1=1

    Changegeometry

    automatically

    Changegeometry

    automatically

    Datatopologically

    checked

    Datatopologically

    checked

    Check topologymanually

    &

    Check topologymanually

    &

    Check topologymanually

    &

    Changegeometrymanually

    Changegeometrymanually

    Datageometrically

    and codedcorrectly

    Datageometrically

    and codedcorrectly

    Check if inbuffer zone

    no

    yes

    Q Check if inbuffer zone

    no

    yesCheck if inbuffer zone

    no

    yesCheck if inbuffer zone

    no

    yesCheck if inbuffer zone

    no

    yes

    QQ

    Topology errorcorrected by

    changinggeometry

    Topology errorcorrected by

    changinggeometry

    Fig. 19: Modelling of topology check and reworking

    By using this quality assurance method the following quality parameter value can beupgraded: if topology errors like gaps and overshoots are corrected, the topologicalcorrectness is upgraded. To evaluate this quality improvement it is assumed thatafter topological reworking the topological correctness value is approx. 99%. Ifexemplarily 2 km from 100 km road are changed topologically, the topologicalcorrectness is upgraded from approx. 97% to 99%.

  • 7/30/2019 D2.4 Quality Management_FD0.1

    19/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 19 (23)

    4.2 Evaluation of quality

    4.2.1 Speed limit information in the testfield Ansbach (Bavaria)

    For evaluation of quality parameter values an example from initial acquisition ofspeed limit information in the EuroRoadS-testfield Ansbach (Bavaria) is given in thefollowing. The acquisition and evaluation of data is organised in cooperation withEuroRoadS-projectpartners PTV AG and Bavarian board of building (Germany).

    In the testfield Ansbach speed limit information will be acquired by using differentacquisition methods:

    implicit speed regulations (exist due to national laws)

    use of local knowledge (communities etc.)

    research in a data base, in which photos of all 20 meters of the major roads in

    Bavaria are compiled (so called STRADIVARI) field enquiry

    The task is, besides others, to evaluate the quality parameter values of attributecorrectness of speed limit information. For this purpose the acquired speed limitinformation of these different acquisition sources will be compared. It is assumed thatthe field enquiry has a rate of correctness of 99%. Compared to this fact the rate ofcorrectness of other methods will be calculated. Furthermore the effort of differentmethods is acquired. The result shows a statement about attribute correctness andeffort of speed limit information, depending on chosen acquisition methods, asillustrated in Fig. 20.

    effort (working timein personmonth;accumulated

    99

    (4) fieldenquiry

    (3) data base

    (2) localknowledge

    (1) implicit

    rate ofchange

    effort (in ;

    quality

    (correctness in%)

    99

    (4) fieldenquiry

    (3) data base

    (2) localknowledge

    (1) implicit

    rate ofchange

    workingtime

    effort (working timein personmonth;accumulated

    99

    (4) fieldenquiry

    (3) data base

    (2) localknowledge

    (1) implicit

    rate ofchange

    effort (in ;

    quality

    (correctness in%)

    99

    (4) fieldenquiry

    (3) data base

    (2) localknowledge

    (1) implicit

    rate ofchange

    workingtime

    Fig. 20: Example for relation of correctness and effortdepending on chosen acquisition method

    Furthermore the quality parameter rate of changeof speed limit information will beevaluated. For this purpose existing ruling papers will be researched, and as a resulta statement can be given about street kilometres, which are concerned by changesof speed limits per year.

    A detailed description of results of quality evaluation in the testfield Ansbach will begiven in the EuroRoadS-Report D7.6 Measuring results.

  • 7/30/2019 D2.4 Quality Management_FD0.1

    20/23

  • 7/30/2019 D2.4 Quality Management_FD0.1

    21/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 21 (23)

    The following phase Checkincludes monitoring and evaluating processes and resultscompared to objectives and specifications. Therefore evaluation methods formeasuring quality parameter values has to be used. Afterwards it has to be verifiedwhether the required product quality is fulfilled.

    The modifications have to be formalised in a quality report. For this purposeprocesses of road information as well as measured quality parameters can beintegrated into metadata. Based on the documentation, a new iteration is to bestarted (Act). Herein a starting point for constant improvement of work can be seen.

    QM of SpeedLimitService

    applicationDisplay

    integration

    Road networkdata + SL

    (AGF)conversion

    Road networkdata + SL

    binary formatprocessingGDF Data

    Road networkdata(AGF)

    export

    Road networkand SL data

    from ERsupplier

    EuroRoadS

    ExchangeFormat

    QM of dataprocessing

    Plan

    DoCheck

    Act

    Plan

    DoCheck

    Act QM of SpeedLimitService

    applicationDisplay

    integration

    Road networkdata + SL

    (AGF)conversion

    Road networkdata + SL

    binary formatprocessingGDF Data

    Road networkdata(AGF)

    export

    Road networkand SL data

    from ERsupplier

    EuroRoadS

    ExchangeFormat

    QM of dataprocessing

    Plan

    DoCheck

    Act Plan

    DoCheck

    Act

    Plan

    DoCheck

    Act Plan

    DoCheck

    Act

    Fig. 22: Quality management concept within the EuroRoadS information chain

    The described tasks and methods of quality management according the PDCA-cyclewill be integrated into EuroRoadS information chain (cf. Fig. 22). The firstimplementations have been started:

    Documentation of processes within the EuroRoadS information chain by usingthe graphical part of probabilistic model.

    Evaluation of quality parameter values at different steps within the EuroRoadSinformation chain by using evaluation methods, e.g.:

    - up-to-dateness and correctness for initial acquisition of speed information

    - geometric accuracy for coordinate thinning within the first steps ofprocessing.

    Identification of potential failures by using the cause and effect diagram andFMEA

    Development of quality assurance measures for initial speed limit acquisitionwithin a testfield.

  • 7/30/2019 D2.4 Quality Management_FD0.1

    22/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 22 (23)

    Annex

    Annex A: ReferencesCerco Working Group on Quality (2000): Handbook for implementing a qualitymanagement system in a national mapping agency.

    CEN European Committee for Standardization (2000): EN - ISO 9000. Qualitymanagement systems Fundamentals and vocabulary(ISO 9000:2000).

    Deming, W.E. (1982): Out of the crisis. Massachusetts Institute of Technology,Centre for Advanced Engineering Study.

    ISO 19113 (2002): Geographic information - quality principles.

    ISO 19114 (2003): Geographic information - quality evaluation procedures.

    ISO 19115 (2003): Geographic information - metadata.

    Kaufmann. T.; Wiltschko, T. (2005): Report on evaluation scheme for informationquality. EuroRoadS project report D2.5.

    Kaufmann, T.; Wiltschko, T. (2006): Metadata Catalogue FD2.0. EuroRoadS projectreport D6.8.

    Kompfner, P. (2005): Evaluation Methodology. EuroRoadS project report D2.1.(www.euroroads.com)

    Landwehr, M.; Escher, A. (2005): EuroRoadS: Specification of the technical system

    and its components. EuroRoadS project report D7.2.Wikstrom, L. (2005): Overview of the EuroRoadS framework documents. EuroRoadSproject document of WP6. (www.euroroads.com).

    Wikstrm, L. (2006): Final draft specification of Road network exchange format.EuroRoadS project report D6.11. (www.euroroads.org)

    Wiltschko, T.; Kaufmann, T. (2004): Report on quality frame for information.EuroRoadS project report D2.2. (www.euroroads.com).

    Wiltschko, T.; Kaufmann, T. (2005): Probabilistic model to describe and evaluateinformation quality. EuroRoadS project report D2.3. (www.euroroads.com).

  • 7/30/2019 D2.4 Quality Management_FD0.1

    23/23

    EuroRoadSReport Date Status Version PageD2.4 2006-02-20 FD 0.1 23 (23)

    Annex B: Glossary

    quality management (ISO 9000)coordinated activities to direct and control an organization with regard to quality

    NOTE Direction and control with regard to quality generally includesestablishment of the quality policy and quality objectives, quality planning, qualitycontrol, quality assurance and quality improvement.

    quality planning (ISO 9000)part of quality management focused on setting quality objectives and specifyingnecessary operational processes and related resources to fulfil the quality objectives

    NOTE Establishing quality plans can be part of quality planning.

    quality control (ISO 9000)part of quality management focused on fulfilling quality requirements

    quality assurance (ISO 9000)part of quality management focused on providing confidence that qualityrequirements will be fulfilled

    quality improvement (ISO 9000)part of quality management focused on increasing the ability to fulfil the qualityrequirements

    NOTE The requirements can be related to any aspect such as effectiveness,efficiency or traceability.

    nonconformity (ISO 9000)

    non-fulfilment of a requirement