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
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
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