Good Practice Guidelines for Risk Management of Software-based Systems
|
|
|
- Jeffery Wright
- 10 years ago
- Views:
Transcription
1 LYPHID ID= 116 NAME= IACUTE /> ID= 293 NAME= UDBLACUTE /> FII10084 /> ID= 443 NAME= NCEDILLA /> ID= 452 NAME= RCEDILLA /> ID= 117 NAME= IGRAVE /> ID= 294 NAME= UDBLACUTE /> FII10085 /> GLYPHID ID= 444 ID= 453 NAME= NCEDILLA /> NAME= SCIRCUMFLEX /> ID= 118 NAME= ICIRCUMFLEX /> ID= 295 NAME= ZACUTE /> FII10086 /> GLYPHID ID= 445 ID= 454 NAME= ENG /> NAME= SCIRCUMFLEX /> ID= 119 NAME= IDIERESIS /> ID= 296 NAME= ZACUTE /> FII10087 /> GLYPHID ID= 446 ID= 455 NAME= ENG /> NAME= TBAR /> ID= 120 NAME= NTILDE /> ID= 297 NAME= ZDOT /> FII10088 /> GLYPHID ID= 447 ID= 456 NAME= OMACRON /> NAME= TBAR /> ID= 121 NAME= OACUTE /> ID= 298 NAME= ZDOT /> FII10089 /> GLYPHID ID= 448 ID= 457 NAME= OMACRON /> NAME= UTILDE /> ID= 122 NAME= OGRAVE /> ID= 299 NAME= GAMMA /> FII10090 /> GLYPHID ID= 449 ID= 458 NAME= OBREVE /> NAME= UTILDE /> ID= 123 NAME= OCIRCUMFLEX /> ID= 300 NAME= THETA /> FII10091 /> GLYPHID ID= 450 ID= 459 NAME= OBREVE /> NAME= UMACRON /> ID= 124 NAME= ODIERESIS /> ID= 301 NAME= PHI /> FII10092 /> GLYPHID ID= 451 ID= 460 NAME= RCEDILLA /> NAME= UMACRON /> ID= 125 NAME= OTILDE /> ID= 302 NAME= ALPHA /> FII10093 /> GLYPHID ID= 452 ID= 461 NAME= RCEDILLA /> NAME= UBREVE /> ID= 126 NAME= UACUTE /> ID= 303 NAME= DELTA /> FII10094 /> GLYPHID ID= 453 ID= 462 NAME= SCIRCUMFLEX /> NAME= UBREVE /> ID= 127 NAME= UGRAVE /> ID= 304 NAME= EPSILON /> FII10095 /> GLYPHID ID= 454 ID= 463 NAME= SCIRCUMFLEX /> NAME= UOGONEK /> ID= 128 NAME= UCIRCUMFLEX /> ID= 305 NAME= SIGMA /> FII10096 /> GLYPHID ID= 455 ID= 464 NAME= TBAR /> NAME= UOGONEK /> ID= 129 NAME= UDIERESIS /> ID= 306 NAME= TAU /> FII10097 /> GLYPHID ID= 456 ID= 465 NAME= TBAR /> NAME= WCIRCUMFLEX /> ID= 130 NAME= DAGGER /> ID= 307 NAME= PHI /> FII10071 /> GLYPHID ID= 457 ID= 466 NAME= UTILDE /> NAME= WCIRCUMFLEX /> ID= 131 NAME= DEGREE /> ID= 308 NAME= UNDERSCOREDBL /> FII10099 /> GLYPHID ID= 458 ID= 467 NAME= UTILDE /> NAME= YCIRCUMFLEX /> ID= 132 NAME= CENT /> ID= 309 NAME= EXCLAMDBL /> FII10100 /> GLYPHID ID= 459 ID= 468 NAME= UMACRON /> NAME= YCIRCUMFLEX /> ID= 133 NAME= STERLING /> ID= 310 NAME= NSUPERIOR /> FII10101 /> GLYPHID ID= 460 ID= 469 NAME= UMACRON /> NAME= LONGS /> ID= 134 NAME= SECTION /> ID= 311 NAME= PESETA /> FII10102 /> GLYPHID ID= 461 ID= 470 NAME= UBREVE /> NAME= ARINGACUTE /> ID= 135 NAME= BULLET /> ID= 312 NAME= ARROWLEFT /> FII10103 /> GLYPHID ID= 462 ID= 471 NAME= UBREVE /> NAME= ARINGACUTE /> ID= 136 NAME= PARAGRAPH /> ID= 313 NAME= ARROWUP /> FII10104 /> GLYPHID ID= 463 ID= 472 NAME= UOGONEK /> NAME= AEACUTE /> ID= 137 NAME= GERMANDBLS /> ID= 314 NAME= ARROWRIGHT /> FII10105 /> GLYPHID ID= 464 ID= 473 NAME= UOGONEK /> NAME= AEACUTE /> ID= 138 NAME= REGISTERED /> ID= 315 NAME= ARROWDOWN /> FII10106 /> GLYPHID ID= 465 ID= 474 NAME= WCIRCUMFLEX /> NAME= OSLASHACUTE /> ID= 139 NAME= COPYRIGHT /> ID= 316 NAME= ARROWBOTH /> FII10107 /> GLYPHID ID= 466 ID= 475 NAME= WCIRCUMFLEX /> NAME= OSLASHACUTE /> ID= 140 NAME= TRADEMARK /> ID= 317 NAME= ARROWUPDN /> FII10108 /> GLYPHID ID= 467 ID= 476 NAME= YCIRCUMFLEX /> NAME= ANOTELEIA /> ID= 141 NAME= ACUTE /> ID= 318 NAME= ARROWUPDNBSE /> FII10109 /> GLYPHID ID= 468 ID= 477 NAME= YCIRCUMFLEX /> NAME= WGRAVE /> ID= 142 NAME= DIERESIS /> ID= 319 NAME= ORTHOGONAL /> FII10110 /> GLYPHID ID= 469 ID= 478 NAME= LONGS /> NAME= WGRAVE /> ID= 143 NAME= NOTEQUAL /> ID= 320 NAME= INTERSECTION /> FII10193 /> GLYPHID ID= 470 ID= 479 NAME= ARINGACUTE /> NAME= WACUTE /> ID= 144 NAME= AE /> ID= 321 NAME= EQUIVALENCE /> FII10050 /> GLYPHID ID= 471 ID= 480 NAME= ARINGACUTE /> NAME= WACUTE /> ID= 145 NAME= OSLASH /> ID= 322 NAME= HOUSE /> FII10098 /> GLYPHID ID= 472 ID= 481 NAME= AEACUTE /> NAME= WDIERESIS /> ID= 146 NAME= INFINITY /> ID= 323 NAME= REVLOGICALNOT /> FII00208 /> GLYPHID ID= 473 ID= 482 NAME= AEACUTE /> NAME= WDIERESIS /> ID= 147 NAME= PLUSMINUS /> ID= 324 NAME= INTEGRALTP /> FII61352 /> GLYPHID ID= 474 ID= 483 NAME= OSLASHACUTE /> NAME= YGRAVE /> ID= 148 NAME= LESSEQUAL /> ID= 325 NAME= INTEGRALBT /> I /> GLYPHID ID= 475 ID= 484 NAME= OSLASHACUTE /> NAME= YGRAVE /> ID= 149 NAME= GREATEREQUAL /> ID= 326 NAME= SF /> HEVA /> GLYPHID ID= 476 ID= 485 NAME= ANOTELEIA /> NAME= QUOTEREVERSED /> ID= 150 NAME= YEN /> ID= 327 NAME= SF /> ATAFSEGOL /> GLYPHID ID= 477 ID= 486 NAME= WGRAVE /> NAME= RADICALEX /> ID= 151 NAME= MU1 /> ID= 328 NAME= SF /> ATAFPATAH /> GLYPHID ID= 478 ID= 487 NAME= WGRAVE /> NAME= AFII08941 /> ID= 152 NAME= PARTIALDIFF /> ID= 329 NAME= SF /> ATAFQAMATS /> GLYPHID ID= 479 ID= 488 NAME= WACUTE /> NAME= ESTIMATED /> ID= 153 NAME= SUMMATION /> ID= 330 NAME= SF /> IRIQ /> GLYPHID ID= 480 ID= 489 NAME= WACUTE /> NAME= ONEEIGHTH /> ID= 154 NAME= PRODUCT /> ID= 331 NAME= SF /> SERE /> GLYPHID ID= 481 ID= 490 NAME= WDIERESIS /> NAME= THREEEIGHTHS /> ID= 155 NAME= PI1 /> ID= 332 NAME= SF /> EGOL /> GLYPHID ID= 482 ID= 491 NAME= WDIERESIS /> NAME= FIVEEIGHTHS /> ID= 156 NAME= INTEGRAL /> ID= 333 NAME= SF /> ATAH /> GLYPHID ID= 483 ID= 492 NAME= YGRAVE /> NAME= SEVENEIGHTHS /> ID= 157 NAME= ORDFEMININE /> ID= 334 NAME= SF /> AMATS /> GLYPHID ID= 484 ID= 493 NAME= YGRAVE /> NAME= COMMAACCENT /> ID= 158 NAME= ORDMASCULINE /> ID= 335 NAME= SF /> OLAM /> GLYPHID ID= 485 ID= 494 NAME= QUOTEREVERSED /> NAME= UNDERCOMMAACCENT /> ID= 159 NAME= OHM /> ID= 336 NAME= SF /> UBUTS /> GLYPHID ID= 486 ID= 495 NAME= RADICALEX /> NAME= TONOS /> ID= 160 NAME= AE /> ID= 337 NAME= SF /> AGESH /> GLYPHID ID= 487 ID= 496 NAME= AFII08941 /> NAME= DIERESISTONOS /> ID= 161 NAME= OSLASH /> ID= 338 NAME= SF /> ETEG /> GLYPHID ID= 488 ID= 497 NAME= ESTIMATED /> NAME= ALPHATONOS /> ID= 162 NAME= QUESTIONDOWN /> ID= 339 NAME= SF /> AQAF /> GLYPHID ID= 489 ID= 498 NAME= ONEEIGHTH /> NAME= EPSILONTONOS /> ID= 163 NAME= EXCLAMDOWN /> ID= 340 NAME= SF /> AFE /> GLYPHID ID= 490 ID= 499 NAME= THREEEIGHTHS /> NAME= ETATONOS /> ID= 164 NAME= LOGICALNOT /> ID= 341 NAME= SF /> ASEQ /> GLYPHID ID= 491 ID= 500 NAME= FIVEEIGHTHS /> NAME= IOTATONOS /> ID= 165 NAME= RADICAL /> ID= 342 NAME= SF /> HINDOT /> GLYPHID ID= 492 ID= 501 NAME= SEVENEIGHTHS /> NAME= OMICRONTONOS /> ID= 166 NAME= FLORIN /> ID= 343 NAME= SF /> INDOT /> GLYPHID ID= 493 ID= 502 NAME= COMMAACCENT /> NAME= UPSILONTONOS /> ID= 167 NAME= APPROXEQUAL /> ID= 344 NAME= SF /> OFPASUQ /> GLYPHID ID= 494 ID= 503 NAME= UNDERCOMMAACCENT /> NAME= OMEGATONOS /> ID= 168 NAME= DELTA /> ID= 345 NAME= SF /> LEF /> GLYPHID ID= 495 ID= 504 NAME= TONOS /> NAME= IOTADIERESISTONOS /> ID= 169 NAME= GUILLEMOTLEFT /> ID= 346 NAME= SF /> ET /> GLYPHID ID= 496 ID= 505 NAME= DIERESISTONOS /> NAME= ALPHA /> ID= 170 NAME= GUILLEMOTRIGHT /> ID= 347 NAME= SF /> IMEL /> GLYPHID ID= 497 ID= 506 NAME= ALPHATONOS /> NAME= BETA /> ID= 171 NAME= ELLIPSIS /> ID= 348 NAME= SF /> ALET /> GLYPHID ID= 498 ID= 507 NAME= EPSILONTONOS /> NAME= DELTA#1 /> ID= 172 NAME= AGRAVE /> ID= 349 NAME= SF /> E /> GLYPHID ID= 499 ID= 508 NAME= ETATONOS /> NAME= EPSILON /> ID= 173 NAME= ATILDE /> ID= 350 NAME= SF /> AV /> GLYPHID ID= 500 ID= 509 NAME= IOTATONOS /> NAME= ZETA /> ID= 174 NAME= OTILDE /> ID= 351 NAME= SF /> AYIN /> GLYPHID ID= 501 ID= 510 NAME= OMICRONTONOS /> NAME= ETA /> ID= 175 NAME= OE /> ID= 352 NAME= SF /> ET /> GLYPHID ID= 502 ID= 511 NAME= UPSILONTONOS /> NAME= IOTA /> ID= 176 NAME= OE /> ID= 353 NAME= SF /> ET /> GLYPHID ID= 503 ID= 512 NAME= OMEGATONOS /> NAME= KAPPA /> ID= 177 NAME= ENDASH /> ID= 354 NAME= SF /> OD /> GLYPHID ID= 504 ID= 513 NAME= IOTADIERESISTONOS /> NAME= LAMBDA /> ID= 178 NAME= EMDASH /> ID= 355 NAME= SF /> INALKAF /> GLYPHID ID= 505 ID= 514 NAME= ALPHA /> NAME= MU /> ID= 179 NAME= QUOTEDBLLEFT /> ID= 356 NAME= SF /> AF /> GLYPHID ID= 506 ID= 515 NAME= BETA /> NAME= NU /> ID= 180 NAME= QUOTEDBLRIGHT /> ID= 357 NAME= SF /> AMED /> GLYPHID ID= 507 ID= 516 NAME= DELTA#1 /> NAME= XI /> ID= 181 NAME= QUOTELEFT /> ID= 358 NAME= SF /> INALMEM /> GLYPHID ID= 508 ID= 517 NAME= EPSILON /> NAME= OMICRON /> ID= 182 NAME= QUOTERIGHT /> ID= 359 NAME= SF /> EM /> ON! GLYPHID --> ID= 509 ID= 518 NAME= ZETA /> NAME= PI /> ID= 183 NAME= DIVIDE /> ID= 360 NAME= SF /> INALNUN /> GLYPHID ID= 510 ID= 519 NAME= ETA /> NAME= RHO /> ID= 184 NAME= LOZENGE /> ID= 361 NAME= SF /> UN /> GLYPHID ID= 511 ID= 520 NAME= IOTA /> NAME= SIGMA /> ID= 185 NAME= YDIERESIS /> ID= 362 NAME= SF /> AMEKH /> GLYPHID ID= 512 ID= 521 NAME= KAPPA /> NAME= TAU /> ID= 186 NAME= YDIERESIS /> ID= 363 NAME= SF /> YIN /> GLYPHID ID= 513 ID= 522 NAME= LAMBDA /> NAME= UPSILON /> ID= 187 NAME= FRACTION /> ID= 364 NAME= SF /> INALPE /> GLYPHID ID= 514 ID= 523 NAME= MU /> NAME= CHI /> ID= 188 ID= 524 NAME= EURO /> ID= 365 NAME= PSI /> NAME= SF /> E /> GLYPHID ID= 515 NAME= NU /> ID= 189 ID= 525 NAME= GUILSINGLLEFT /> ID= 366 NAME= OMEGA /> NAME= UPBLOCK /> INALTSADI /> GLYPHID ID= 516 NAME= XI /> ID= 190 ID= 526 NAME= GUILSINGLRIGHT /> ID= 367 NAME= IOTADIERESIS /> NAME= DNBLOCK /> SADI /> GLYPHID ID= 517 NAME= OMICRON /> ID= 191 ID= 527 NAME= FI /> ID= 368 NAME= UPSILONDIERESIS /> NAME= BLOCK /> OF /> GLYPHID ID= 518 NAME= PI /> ID= 192 ID= 528 NAME= FL /> ID= 369 NAME= ALPHATONOS /> NAME= LFBLOCK /> ESH /> GLYPHID ID= 519 NAME= RHO /> ID= 193 ID= 529 NAME= DAGGERDBL /> ID= 370 NAME= EPSILONTONOS /> NAME= RTBLOCK /> HIN /> GLYPHID ID= 520 NAME= SIGMA /> ID= 194 ID= 530 NAME= PERIODCENTERED /> ID= 371 NAME= ETATONOS /> NAME= LTSHADE /> AV /> GLYPHID ID= 521 NAME= TAU /> ID= 195 ID= 531 NAME= QUOTESINGLBASE /> ID= 372 NAME= IOTATONOS /> NAME= SHADE /> OUBLEVAV /> GLYPHID ID= 522 NAME= UPSILON /> ID= 196 ID= 532 NAME= QUOTEDBLBASE /> ID= 373 NAME= UPSILONDIERESISTON NAME= DKSHADE /> AVYOD /> GLYPHID ID= 523 NAME= CHI /> OS /> ID= 197 NAME= PERTHOUSAND /> ID= 374 NAME= FILLEDBOX /> OUBLEYOD /> GLYPHID ID= 524 NAME= PSI /> ID= 198 ID= 533 NAME= ACIRCUMFLEX /> ID= 375 NAME= BETA /> NAME= FILLEDRECT /> ERESH /> GLYPHID ID= 525 NAME= OMEGA /> ID= 199 ID= 534 NAME= ECIRCUMFLEX /> ID= 376 NAME= GAMMA /> NAME= TRIAGUP /> ERSHAYIM /> GLYPHID ID= 526 NAME= IOTADIERESIS /> ID= 200 ID= 535 NAME= AACUTE /> ID= 377 NAME= ZETA /> NAME= TRIAGRT /> EWSHEQELSIGN /> GLYPHID ID= 527 NAME= UPSILONDIERESIS /> ID= 201 ID= 536 NAME= EDIERESIS /> ID= 378 NAME= ETA /> NAME= TRIAGDN /> AVSHINDOT /> GLYPHID ID= 528 NAME= ALPHATONOS /> ID= 202 ID= 537 NAME= EGRAVE /> ID= 379 NAME= THETA /> NAME= TRIAGLF /> INALKAFSHEVA /> GLYPHID ID= 529 NAME= EPSILONTONOS /> ID= 203 ID= 538 NAME= IACUTE /> ID= 380 NAME= IOTA /> NAME= CIRCLE /> INALKAFQAMATS /> GLYPHID ID= 530 NAME= ETATONOS /> ID= 204 ID= 539 NAME= ICIRCUMFLEX /> ID= 381 NAME= KAPPA /> NAME= INVBULLET /> AMEDHOLAM /> GLYPHID ID= 531 NAME= IOTATONOS /> ID= 205 ID= 540 NAME= IDIERESIS /> ID= 382 NAME= LAMBDA /> NAME= INVCIRCLE /> AMEDHOLAMDAGESH /> GLYPHID ID= 532 NAME= UPSILONDIERESISTONOS /> ID= 206 ID= 541 NAME= IGRAVE /> ID= 383 NAME= MU /> NAME= SMILEFACE /> LTAYIN /> GLYPHID ID= 533 NAME= BETA /> ID= 207 ID= 542 NAME= OACUTE /> ID= 384 NAME= NU /> NAME= INVSMILEFACE /> HINSHINDOT /> GLYPHID ID= 534 NAME= GAMMA /> ID= 208 ID= 543 NAME= OCIRCUMFLEX /> ID= 385 NAME= XI /> NAME= SUN /> HINSINDOT /> GLYPHID ID= 535 NAME= ZETA /> ID= 209 ID= 544 NAME= OGRAVE /> ID= 386 NAME= OMICRON /> NAME= FEMALE /> HINDAGESHSHINDOT /> GLYPHID ID= 536 NAME= ETA /> ID= 210 ID= 545 NAME= UACUTE /> ID= 387 NAME= RHO /> NAME= MALE /> HINDAGESHSINDOT /> GLYPHID ID= 537 NAME= THETA /> ID= 211 ID= 546 NAME= UCIRCUMFLEX /> ID= 388 NAME= SIGMA1 /> NAME= SPADE /> LEFPATAH /> GLYPHID ID= 538 NAME= IOTA /> ID= 212 ID= 547 NAME= UGRAVE /> ID= 389 NAME= UPSILON /> NAME= CLUB /> LEFQAMATS /> GLYPHID ID= 539 NAME= KAPPA /> ID= 213 ID= 548 NAME= DOTLESSI /> ID= 390 NAME= CHI /> NAME= HEART /> LEFMAPIQ /> GLYPHID ID= 540 NAME= LAMBDA /> ID= 214 ID= 549 NAME= CIRCUMFLEX /> ID= 391 NAME= PSI /> NAME= DIAMOND /> ETDAGESH /> GLYPHID ID= 541 NAME= MU /> ID= 215 ID= 550 NAME= TILDE /> ID= 392 NAME= OMEGA /> NAME= MUSICALNOTE /> IMELDAGESH /> GLYPHID ID= 542 NAME= NU /> ID= 216 ID= 551 NAME= MACRON /> ID= 393 NAME= IOTADIERESIS /> NAME= MUSICALNOTEDBL /> ALETDAGESH /> GLYPHID ID= 543 NAME= XI /> ID= 217 ID= 552 NAME= BREVE /> ID= 394 NAME= UPSILONDIERESIS /> NAME= IJ /> EDAGESH /> GLYPHID ID= 544 NAME= OMICRON /> ID= 218 ID= 553 NAME= DOTACCENT /> ID= 395 NAME= OMICRONTONOS /> NAME= IJ /> AVDAGESH /> GLYPHID ID= 545 NAME= RHO /> ID= 219 ID= 554 NAME= RING /> ID= 396 NAME= UPSILONTONOS /> NAME= NAPOSTROPHE /> AYINDAGESH /> GLYPHID ID= 546 NAME= SIGMA1 /> ID= 220 ID= 555 NAME= CEDILLA /> ID= 397 NAME= OMEGATONOS /> NAME= MINUTE /> ETDAGESH /> GLYPHID ID= 547 NAME= UPSILON /> ID= 221 ID= 556 NAME= HUNGARUMLAUT /> ID= 398 NAME= AFII10023 /> NAME= SECOND /> ODDAGESH /> GLYPHID ID= 548 NAME= CHI /> GLYPHID ID= 222 ID= 549 ID= 557 NAME= OGONEK /> NAME= PSI /> ID= 399 NAME= AFII10051 /> NAME= AFII61248 /> INALKAFDAGESH /> GLYPHID ID= 223 ID= 550 ID= 558 NAME= CARON /> NAME= OMEGA /> ID= 400 NAME= AFII10052 /> NAME= AFII61289 /> AFDAGESH /> GLYPHID ID= 224 ID= 551 ID= 559 NAME= LSLASH /> NAME= IOTADIERESIS /> ID= 401 NAME= AFII10053 /> NAME= H22073 /> AMEDDAGESH /> GLYPHID ID= 225 ID= 552 ID= 560 NAME= LSLASH /> NAME= UPSILONDIERESIS /> ID= 402 NAME= AFII10054 /> NAME= H18543 /> EMDAGESH /> GLYPHID ID= 226 ID= 553 ID= 561 NAME= SCARON /> NAME= OMICRONTONOS /> ID= 403 NAME= AFII10055 /> NAME= H18551 /> UNDAGESH /> GLYPHID ID= 227 ID= 554 ID= 562 NAME= SCARON /> NAME= UPSILONTONOS /> ID= 404 NAME= AFII10056 /> NAME= H18533 /> AMEKHDAGESH /> GLYPHID ID= 228 ID= 555 ID= 563 NAME= ZCARON /> NAME= OMEGATONOS /> ID= 405 NAME= AFII10057 /> NAME= OPENBULLET /> INALPEDAGESH /> GLYPHID ID= 229 ID= 556 ID= 564 NAME= ZCARON /> NAME= AFII10023 /> ID= 406 NAME= AFII10058 /> NAME= AMACRON /> EDAGESH /> GLYPHID ID= 230 ID= 557 ID= 565 NAME= BROKENBAR /> NAME= AFII10051 /> ID= 407 NAME= AFII10059 /> NAME= AMACRON /> SADIDAGESH /> GLYPHID ID= 231 ID= 558 NAME= ETH /> NAME= AFII10052 /> ID= 408 NAME= CCIRCUMFLEX /> OFDAGESH /> GLYPHID ID= 232 ID= 559 NAME= ETH /> NAME= AFII10053 /> ID= 409 NAME= CCIRCUMFLEX /> ESHDAGESH /> GLYPHID ID= 233 ID= 560 NAME= YACUTE /> NAME= AFII10054 /> ID= 410 NAME= CDOT /> HINDAGESH /> GLYPHID ID= 234 ID= 561 NAME= YACUTE /> NAME= AFII10055 /> ID= 411 NAME= CDOT /> AVDAGES /> GLYPHID ID= 562 NAME= AFII10056 /> ID= 412 NAME= EMACRON /> AVHOLAM /> GLYPHID ID= 563 NAME= AFII10057 /> ID= 413 NAME= EMACRON /> ETRAFE /> AFRAFE /> GLYPHID ID= 564 NAME= AFII10058 /> ERAFE /> GLYPHID ID= 565 NAME= AFII10059 /> GLYPHID ID= 566 NAME= AFII10060 /> Good Practice Guidelines for Risk Management of Software-based Systems March 2007 The New Zealand Computer Society Inc.
2 2
3 CONTENTS Minister s Foreword Foreword Introduction Risk Concepts in the Engineering Context Risk Assessment Risk Reduction The Effectiveness-case Summary Acknowledgements References Appendix 1: Critical Software Systems
4 MINISTER S FOREWORD New Zealand s future economic development and international competitiveness is reliant upon improving our digital capability, infrastructures and skills across government, the business sector and communities. These aims are brought together in the Labour-led Government s Digital Strategy. Underpinning many of these areas is reliance upon international good practice and conformance with internationallyrecognised standards. In the area of software engineering standards IPENZ has taken a leadership role and developed Good Practice Guidelines for Software Engineering in New Zealand. Increasingly, New Zealand software development companies will need to conform to accepted international benchmarks in order to remain internationally competitive. These guidelines mean that New Zealand companies will have a point of reference for the standards required by the global software market when developing new products. The Government recognises that these guidelines are important. Industry-led initiatives, such as the development of these guidelines, assist in New Zealand s transformation into an innovative, knowledge-based, internationallycompetitive economy. Therefore, I commend the Institution and its collaborators for undertaking this valuable work. Hon David Cunliffe 2
5 FOREWORD New Zealand s economic development relies on good practices for developing and operating software-intensive systems. Moreover, to strengthen New Zealand s export competitiveness both in terms of cost structures and delivered product quality software development organisations must adopt the good practices already being used elsewhere around the world. The fi nancial transaction component of our economy has been largely digital for many years now. We are also rapidly implementing digital government through initiatives fl owing from the Government s Digital Strategy. But these critical infrastructures for our 21st century economy fundamentally rely on trustworthy software-intensive systems. Already our society is highly dependent on software intensive systems, and in turn their defi nition, development, implementation and operations. Obvious everyday examples include: electronic cash registers used for virtually all purchasing whatever the fi nal payment mechanism might be stock control systems monitoring and control systems for public utilities, transportation systems and health care rapid and easy web-based access to government-held information industrial control systems Building and operating these kinds of critical systems are dependent on good practices across the whole softwareintensive system lifecycle, such as those codifi ed by international software engineering standards and maturity frameworks. While slavishly following good practices won t guarantee reliable or cost-effective development and operations, poor or mediocre practices make reliability and effectiveness a matter of chance rather than good management. There are many other reasons for referring to documented good practices. They: foster traceability of features delivered to meet customers requirements describe ways of avoiding risks caused by the failure of software-intensive systems provide checklists of procedures and practices that improve the overall effi ciency of software development processes encompass considerations for building in and maintaining security, privacy and resilience to malicious attacks In short, good practices as embodied in international software standards and frameworks are the roadmaps towards a disciplined approach to software systems development and operations. 3
6 INTRODUCTION In a hardware-based engineering project, managing risks is one facet of overall project management. A risk assessment should be carried out in the initial stages of the project, followed by a number of related activities and reviews during the development of the design. The risk management process identifi es areas that need special care during the operational life of the project (from initial concept development, through implementation and operation, to fi nal disposal) and will ensure the use of suitable procedures to minimise risk and ensure that overall project management takes risk into account. While risk management is often concerned with issues related to the physical safety of people who will use the fi nal product, other areas of risk exposure such as fi nancial viability and environmental effects are often considered at the same time. In many cases, the overall risk may mostly depend on these other areas. With software-based systems, there is the same need to identify risks associated with the project, and ensure the use of appropriate management techniques. This document examines standard engineering practice for risk management, and how it applies to a project that involves large software engineering content. RISK CONCEPTS IN THE ENGINEERING CONTEXT In this context, the term risk has a slightly different meaning from that used in normal conversation. In everyday use, risk refers to an element or effect that has some potentially damaging consequences. In engineering work, the risk associated with a project is a measure of the potential cost associated with undesirable effects, and considers both the probability of a damaging event and the severity of the damage done if that event should come to pass. A useful parallel is to consider a hazard on a golf course. In this case, the damaging event is a ball landing in the hazard, and the average number of extra strokes needed to get out of the hazard can measure the potential severity. While this measure indicates the potential damage to a scorecard if a golfer happens to hit the hazard, it only gives a partial indication of the potential impact of the hazard. To look at the relative signifi cance of a hazard compared to others, we also have to look at the likelihood that a ball will actually land in the hazard. A given design of hazard may be relatively benign if located well away from the hole and off the fairway, but cause many problems if located in a critical location. We can assign a relative cost to golfi ng hazards by counting the number of additional strokes they impose over a period, or converting this to an average cost per player. Players could potentially use this information to develop a strategy for a particular hole to minimise the total cost to their scorecards, by managing club and shot selection. The impact of landing in a hazard on a particular player s scorecard may be reduced if the player develops skills in removing the ball from a sand-trap this is an example of what we will refer to as mitigation. In a similar fashion, engineering risk looks at a number of identifi ed hazards associated with a project over a period and the total cost they may cause. This information is then used to identify the most signifi cant contributions to the overall risk budget and develop appropriate strategies to minimise the potential losses. These measures focus on hazards that have the potential to cause the most damage, and include techniques to remove hazards or minimise the potential damage of those that cannot be removed, and take precautions that reduce the severity of any resulting damage. 4 A complete study of the risks associated with a hardware-based design project must look at all possible hazards throughout the operational life of the system. This lifecycle covers activities from development, construction and commissioning through the productive period to fi nal decommissioning, demolition and disposal. In a project involving software, the physical activities associated with construction and commissioning may be relatively minor, but there may be hazards associated with introducing new software into a system already in operation, for example. Care must be taken when removing software to avoid affecting programmes that remain in use, and there are
7 also problems that have arisen with dead software that is left in a computer but is not actually being used. Data stored in computers marked for disposal must be deleted. Software hazards can also arise through the way the system is operated. For example, one of the problems associated with the Therac particle accelerator that overdosed six patients was due to an operator who was very familiar with the system and made a number of keystrokes in rapid succession 1. In the notes that follow, the following terminology is used: Hazard a condition that has the potential to cause unwanted costs or damage. Hazardous event an event whereby a hazard actually causes unwanted costs or damage. Likelihood of a hazardous event the expected frequency of the event occurring, measured as a number of events in a specifi ed time. Alternatively, this is the probability that the event will occur within a specifi ed time. Severity of a hazard the potential cost that might arise from the hazard. It is expressed in a consistent way for all hazards assessed, to allow meaningful comparisons of the relative impact of each hazard. Mitigation a measure or measures that reduce the severity of a particular hazardous event, once that event has occurred. Risk associated with a hazard the expected cost of a hazard over a period. It is determined numerically by multiplying the severity of a hazard by the sum of the likelihoods of the hazardous events. Control of systematic failures requires that processes carried out during the project lifecycle are carefully managed. They are minimised by factors such as good communications between individuals or groups involved in different activities, making sure that all parties involved are aware of assumptions or limitations in scope, or clearly conveying the intention of the developers to end-users. Systematic failures in computer-based projects may also occur in the interface between hardware and software. The differences between random failures, which are effectively treated with well-developed mathematical methods, and systematic or functional failures, must be remembered in any exercise to manage risk in software-based systems. In situations involving multi-component systems, failures are often not the result of problems with hardware elements or malfunctions in software items. They are more likely to arise from incorrect interactions between the elements of a system, or between the system and the environment (Leveson, 2002). A failure resulting in loss may involve organisational or management aspects of the design or operational system rather than specifi c identifi able hardware or software elements, or the commonly blamed human error at the point of application. Systematic failures can occur at any stage of the project lifecycle, from initial concept development through to actual operational or productive activities. Failure Types Random, Systematic or System Hardware failures are generally random in nature. Standard models are based on a well-defi ned pattern of failure, described in terms of predictable failure rates and related information. Random failures of this kind can be reduced by increasing safety margins between the capability of the target system and the demands made on it by the application. While hardware factors may contribute to the failure of a programmable system, problems arising from defects in software are generally not random and cannot be described by a predictable failure rate. They arise from particular combinations of circumstances, and are perfectly repeatable if the same circumstances recur. These failures are systematic or functional the latter term indicates that they are due to the incorrect functioning of the system in some cases. Simply increasing safety factors will not reduce the incidence of systematic failures. These failures generally arise through oversights in specifi cation, invalid assumptions made during design and development, and mistakes during detailed design. 5 1 An extract discussing the Therac-25 accidents is available at sunnyday.mit.edu/therac-25.html
8 RISK ASSESSMENT 6 AS/NZS 4360: 2004 Risk Management gives a well-established and widely recognised process for managing risk in a general business environment. The steps set out here cover the fi rst four stages of the AS/NZS 4360 process, covering the identifi cation and evaluation of risk. Other stages included in this document cover treatment of hazards and ongoing monitoring and review activities. The fi rst stage of the risk management process is to establish the context for the project, and identify and assess the risks to which the project could be exposed. Where safety issues are concerned, identifi cation of hazards is an explicit requirement placed on the owner or operator of a project by occupational health and safety legislation. There are also related obligations on designers and others involved in the development, implementation and operational phases. The risk assessment process has four stages. These can be summarised as: What could go wrong? Identify the hazards. What happens if it does? Analyse the consequences. What can we do to avoid it? Identify possible preventive measures. What can we do if it does happen? Evaluate mitigation measures. A major benefi t of the risk assessment activity is that it makes people involved with the project aware of the possibility that things could go wrong, and that there is a need to take some special precautions. It should be a team activity with all the groups involved in the fi nal project, and treated as an educational or training exercise as well as an engineering activity. One of the outcomes from the risk assessment should be an indication of the overall cost that hazards will have on the project during its lifetime including the cost of prevention and mitigation measures, and a reasonable estimate of the potential losses. A formal risk assessment process needs to be carried out in a controlled fashion, and the results fully documented and made available to all interested parties. However, risk assessment should also become an activity that is built in to the decisionmaking process at a very low level team members should be aware of the possible impact of their decisions and act accordingly. No golfer will systematically analyse the risk associated with bunkers this becomes an automatic reaction, affected on the day by other infl uences such as wind direction. Context A product designed for experienced adults may be dangerous if used by children or those without specifi c training. This is an example of how the different uses for a product may affect the overall risk. The same applies to systems that include software components. If a software package is to be used for limited purposes by people who are very familiar with it, the associated risk may be very small. However, if the package is adopted for use in a different environment, or made available to less experienced users, the likelihood of error is much greater. Context also applies to the total system in which a software package may be used. If designed for use on a stand-alone computer, there is no need to consider the possibility of malicious damage by unauthorised users accessing the system via the Internet. However, if the package is used on a connected system, this problem must be addressed. Context may involve the hardware platform intended to run the software, and may be affected by the hardware confi guration of the platform. Many industrial software packages were originally written using the standard PC serial port to communicate with target hardware. With the replacement of the serial port in laptops with USB ports, some of these packages can no longer be used. Context may also be concerned with the size of the associated application. An example of a factor affected by size is the time to access information in a large database. This may also be adversely affected by the number of users trying to access the system at one time. Details of the context in which a software component may be used should be set out in a User Requirements Specifi cation or similar document. Hazard Identification The fi rst step in any engineering activity should identify the hazards associated with the proposal. It is important to list not only the specifi c hazards associated with the normal day-today running of the project, but to consider those that come about during the implementation and disposal phases, and any extraordinary activities during operation. In a hardware-based engineering project, the hazards are directly associated with the activities being monitored or controlled, and a hazardous event is triggered by something outside the monitoring, control or protective system. Some examples of typical hazards are high pressures or temperatures, moving machinery, or corrosive chemicals. Hazardous events involve conditions outside the normal working range, malfunction of machinery or injury due to incorrect operating procedures, or unexpected releases. These hazards tend to be well-documented and are often identifi ed using check-lists created during similar exercises.
9 Hazards peculiar to a specifi c context and not generally applicable should be specifi ed in the project brief. In software terms, they should be spelt out in the User Requirements Specifi cation. However, the design team must also act to establish whether hazards other than those specifi ed are likely to be involved. Formal procedures such as a HAZOP review attempt to force the review team to consider a wide range of possible hazards. It is increasingly being recognised (Leveson, 2005) that physical events such as component failure have less effect on the total project risk than system failures, often involving management issues during project development or operation. As stated above, these types of failure are the main contributors to software-related risks. Because they are less tangible and poorly recognised (if recognised at all) in incident reports, they are often overlooked during hazard assessment. However, it is important to identify any assumptions made during a risk assessment that involve factors relating to the risk one example is the extent of training or other competencies required of those working with the system. Problems usually arise in hardware systems when there is an abnormal event of some kind, so that the system deviates from its normal operating regime. Codes of Practice set out acceptable procedures to follow during design or operation. Legislation may require a design to comply with these Codes or provide evidence that work is to a similar or higher standard. Where software is involved in a protective system, a software failure could affect the ability of the system to respond correctly when required. In this context, a software failure is not often regarded as a hazard in its own right it will be considered along with the underlying physical hazard. However, it is also possible for a software fault to trigger an incident without an external event the software failure itself is the trigger event that is directly responsible for loss. No outside event initiates the problem. Some generic headings for pure software hazards could be (Howard et al, 2005): data corruption for example, buffer overfl ow deliberate misuse or malicious intervention (hacking) invalid data entry errors in specifi cation, program design, or development activities hardware failure incompatible software modules in a multi-tasking system Other more specifi c hazards must be itemised for individual projects. It needs to be emphasised that many hazards are introduced by failings in the wider management system rather than specifi c problems arising from either hardware or software. For critical systems, project managers must take care to use control or monitoring practices that are commensurate with the degree of risk if a failure occurs. Identify Consequences A hazardous event associated with any of the identifi ed hazards may give rise to a number of different undesirable outcomes. These are even more context-dependent than the hazards. Some consequences to consider are: physical safety issues where failure of software or hardware may directly result in injury or adversely affect health These apply particularly to programmable systems used in industrial applications to provide protection or supervision of dangerous processes. There have been several cases where failings in medical computer systems have been responsible for patients receiving incorrect dosages of medication. Software used to make engineering calculations needs to have proper testing, verifi cation and validation to make sure the calculations are correct. economic damage Financial effects are probably the major potential consequence of a software system failure. There are a number of ways this could arise from errors in accounting applications to failure to account for specifi c factors. legal consequences Where software is used to comply with legal obligations, incorrect operation might leave an organisation open to prosecution. environmental damage This is another consequence that may apply mainly to process control or supervision applications. Records such as Material Safety Data Systems may cause damage if, for example, the properties of a substance are wrongly recorded. public opinion While not directly related to hard engineering or fi nancial damage, this topic needs to be specifi cally addressed. Events that appear to be relatively minor from an engineering or fi nancial viewpoint may attract a disproportionate level of publicity compared with the measurable consequences. Failings in this area may cause loss of future 7
10 business, additional costs to an organisation because of increased problems obtaining planning permission, or a need for increased advertising or other expenditure to overcome the damage. Bad publicity may also result in indirect fi nancial loss through a drop in the organisation s share price. In a software context, the consequences of a failure are not often physical. While physical damage to hardware must be considered, for example by developing disaster recovery plans, much of the harm arising from a software system failure is likely to be fi nancial. Evaluate Consequences Once the consequences have been identifi ed, they must be ranked in some way to make sure that the resources available for risk control are used to best effect. While public opinion may be a good reason to devote resources to high-profi le outcomes that may in fact have a low impact and are very unlikely to occur, this needs to be properly justifi ed rather than be an automatic reaction. There is always a danger that a major hazard may be overlooked or neglected because resources are used to deal with a hazard that is much less signifi cant. A number of methods have been used to evaluate the consequences of failure in hardware systems and are well described in the literature 2. Applying these methods to software may not work so well. The traditional methods use expected probability as one of the parameters, but as we have seen this may not be relevant to software systems where functional or systematic failures are more likely to be signifi cant. A number of tools can rank hazards based on the possible consequences. A very simple approach is to assign hazards a ranking from 1 4 based on the severity of consequences, with another ranking of 1 4 based on the expected probability. The overall ranking is found by multiplying the two rankings, giving a value of While this method is simple and relatively easy to implement, it is artifi cially precise in its results. For example, the ranking of a hazard with severity of four and probability of two is eight, while a hazard with probability ranking of three and severity of three has a relative risk which is one point higher. In reality, these situations need further analysis to sort out their relative signifi cance, or they would be given the same priority for treatment. Some qualitative methods are given as examples in IEC Standard 61508: Functional Safety of Electrical/Electronic/ Programmable Electronic Safety-Related Systems (International Electrotechnical Commission, ). In each of these, factors affecting the overall risk level are assigned to classes or ranges, which are then used to indicate a requirement for the integrity of the resulting system. While specifi c to issues relating to personnel safety, these techniques can be easily amended to other aspects of risk. We will look at these in more detail in a later section. FIGURE 1: REDUCING PROBABILITY OF FAILURE SEVERITY High Probability Measures Initial Risk Medium Mitigation Measures Tolerable Risk Low Low Medium High Probability 8 RISK REDUCTION 2 See for instance: Smith D J 2005, Reliability, Maintainability and Risk, Butterworth-Heinemann.
11 RISK REDUCTION The ideal target for risk for any project is zero. However, it is not practical to expect to reach this, and in the real world, there will always be some risk attached to any activity, regardless of the resources used to deal with it. The practical engineering objective is to reduce the risk associated with an activity to a level that can be tolerated in the context where that risk arises. Tolerable Risk One of the initial decisions that should be made in any project is the level of risk that is tolerable. This may depend on the size of the organisation that will use the product a large multinational organisation has many more resources than a small start-up fi rm, and may be prepared to underwrite a much higher level of costs arising from hazards. If the total overall risk cannot be reduced below the tolerable level, the project viability must be reconsidered. The tolerable risk is a performance fi gure that that has to be taken into account when making any engineering decisions. A design with a level of risk well below the tolerable level may have been over-engineered, while one that does not meet this target will be unacceptable on safety or related grounds. Tolerable risk is usually defi ned in terms of the total risk arising from all hazards associated with the project. When dealing with individual hazards, the tolerable risk associated with a single hazard must be much less than the overall tolerable value. In general, the tolerable risk associated with a single protective function should be between 10 and 100 times less than the overall tolerable risk for the operation as a whole (Timms, 2006). In general, the overall risk obtained during the risk assessment phase will be well above the tolerable level. If the raw risk associated with any hazard is well below the tolerable level, no further action is needed in relation to that hazard. However there will be some hazards that carry a risk that is much higher, and these need to be reduced in some way. Initially, resources used for risk reduction will be most effective if applied to the hazards having the highest risk, and the risk assessment exercise will target these areas. The ALARP principle is a guide to the amount of risk reduction that is necessary. ALARP ALARP stands for As Low As Reasonably Practicable. It expresses the concept that risks need to be reduced to a level that is low enough, but not too low. The terminology introduces a couple of signifi cant points to take into account in any risk evaluation exercise. Any risk evaluation exercise is inherently uncertain. In a wellengineered project, hazardous events should have a very low probability of occurring during the total life of the project. However, it is not possible to guarantee that they will not arise. You can never state that there is no risk associated with an activity of any sort. When those with a high probability have been attended to, low-probability hazards will remain. However, a level of risk that is too high makes the project unsustainable. Because of this, as part of the overall project objectives, there should be some statement regarding what is an acceptable risk for the project. The reasonable component of ALARP is very vague and generally not regarded with favour by lawyers. However, it does refl ect that there is a need for engineering judgement as to what is reasonable in a given context. Generally, if a risk prevention measure costs more to implement than the amount it reduces the overall risk to the project, it is unreasonable to expect the measure to be applied. The ALARP concept divides the range of risks into three regions. Unacceptable, high-risk levels are classed as intolerable, with very low risks classifi ed as broadly acceptable. The United Kingdom Health and Safety Executive has published guidelines relating these classes to the probability of fatality per person per year in their publication Reducing Risks Protecting People (2001). In this document, the threshold for a risk to be classed as intolerable is a probability of fatality of per person per year if the affected person is an employee. For a member of the public, the threshold is Risks less than are considered as broadly acceptable while less than is negligible. Reducing Probability of Failure Risks can be reduced in a number of ways. If the probability of the initiating event can be reduced, this will have a direct impact on the overall risk. With some hazards, the probability of the initiating hazardous event is outside the control of the engineer an example in civil engineering is the frequency of earthquakes in a particular location. However, with other hazards, the initiating event is a failure of some sort, and here the frequency of failure can be controlled to some extent by design decisions. In designing a car, engineering measures such as anti-lock brakes are intended to reduce the likelihood that the driver will lose control and go into a skid. (See Figure 1 on page 8.) Reducing Severity Mitigation Mitigation measures act to reduce the severity of the outcome, given that a hazardous event has occurred. Where the underlying frequency of hazardous events cannot be reduced, as with earthquakes, engineering measures such as seismic isolation of buildings reduce the impact of the event, and are a form of mitigation. Mitigation measures may be used with protective measures to minimise the overall risk. The airbag in a car is an example of mitigation it is intended to reduce injury in the event of a loss of control. The combined system of anti-lock brakes and airbag includes elements to reduce the probability of a skid, and elements to reduce the impact of a skid should one occur. 9
12 THE EFFECTIVENESS-CASE 10 The process of assessing risks identifi es the problems that have to be addressed during the design and development process in order to meet the performance objectives of the system, whether these relate to safety, reliability or other related measures. Part of the activity during the development phase must ensure that these problems are addressed, and that the system meets the specifi ed performance requirements. While it is possible to comply with requirements using an informal process and modifying the design as a result of reviews, it is far more effective to consider performance issues at the outset and decide on strategies to deal with these issues. Development of a product, and its subsequent operation and maintenance, are made much easier if the decisions made during initial development are documented in a suitable form. Documentation may also be specifi cally required by legislation or in the terms of a contract. A safety-case, in applications involving physical risk, is a document that demonstrates that a system is acceptably safe to operate in a particular context. It must include evidence about the system performance after hazardous events, and set out the arguments linking this evidence to particular requirements of safety performance. A great deal of work has been done in this area in recent years, particularly by the Department of Computer Science at the University of York in the United Kingdom. Much of this aims at the process to prepare a safety-case and formalising its structure. While aimed specifi cally at the issue of demonstrating safety, the approach extends easily to cover other areas of risk. A generic term to cover these other aspects is the effectivenesscase, and this will be used in the discussions below. Goal Structuring Notation Much of the work done at the University of York and other institutions uses a graphical format to demonstrate how a system s performance requirements can be met. This is done by defi ning goals, and then setting out strategies to meet these goals. In many cases, a goal will have a number of associated sub-goals. This work is based on a PhD thesis by Kelly (1998). There are many parallels between the use of the Goal Structuring Notation (GSN) and the ideas of top-down development, and just as the details of a design are refi ned during the development process, the effectiveness-case should evolve as well. The top-level of the effectiveness-case using GSN is a statement, in the form of a logical proposition. This is the goal that is to be proven. For example, a generic goal could be: System X meets the requirements for operation as specifi ed in Document 123. This goal has some specifi c items that identify the particular context. We are dealing with System X, and the specifi c document setting out the requirements is also identifi ed. The basic format of a GSN document would identify strategies to demonstrate this. In our example, we could elaborate on this with strategies to cover the safety requirements, environmental consequences, and fi nancial aspects of the performance specifi cation. Each of these strategies may then result in a series of sub-goals. The process continues until a strategy can be demonstrated to be complete by some action this is then a basic solution. Kelly highlights the need for careful attention to syntax in this process. A goal is a logical proposition to be proved, and must be written using a <noun-phrase> <verb-phrase> format. Strategies are not methods of achieving the desired result they are ways to demonstrate that the result has been met. Kelly gives an example where the strategy use mechanical interlocks is incorrect it refers to a design decision rather than to the way in which that decision can be evaluated. His recommended wording for this strategy is argument by appealing to effectiveness of mechanical interlocks in design. As an instruction, this becomes argue by appealing to. Dealing with Failure Modes The standard techniques to assess risk or demonstrate effectiveness of hardware-based systems use statistical approaches such as Fault Tree Analysis or Failure Modes and Effects Analysis (FMEA). Because these apply to failure modes that are essentially random, they are not well suited for dealing with systematic failures with software systems, or to system failures at management level. This difference can be explicitly dealt with using GSN, by identifying different strategies as being suitable to assess different failure modes. For random failures, a suitable strategy could be: Argue by using Fault Tree to demonstrate an acceptably low failure rate. Systematic failures can be minimised by following appropriate procedures in the product, or by using techniques such as inspection or testing during development. The strategy associated with these can be written in a form such as: Demonstrate that the design process used is appropriate to the risk level. System Integrity Level The strategies used to demonstrate an effectiveness-case must include references to the integrity of any protective measures. It must be possible to show that any features that protect against a hazardous event will in fact be effective if that event occurs.
13 Another consideration (that is sometimes overlooked) is that some systems must not operate unless the target incident occurs airbags in cars are a good example of this. IEC defi nes safety integrity for protective systems as measured by the probability of failure of the system under consideration. It categorises integrity into four Safety Integrity Levels (SIL 1 4), with SIL 1 the least rigorous and SIL 4 the most severe. For safety systems, which operate under exceptional circumstances, the required SIL is based on the probability that the system will fail to operate when a legitimate demand occurs the Probability of Failure on Demand (PFD). For protective systems with a high demand rate, such as machine guards, the SIL is determined by the reliability of the equipment expressed in failures per hour. For political reasons, IEC is concerned solely with safety systems. It is not concerned with the effects of a spurious activation of the safety system, although these may have some adverse effects. However, the SIL is useful in areas where the critical nature of the system is not specifi cally safety-related, and in these cases it can be thought of as system integrity level rather than safety integrity level. It will be used in this sense in this document. FIGURE 2: SYSTEM INTEGRITY LEVEL Low Demand High Demand System Integrity Probability of Failures per hour Level failure on demand The SIL required for a particular protective function can be found by assessing the risk to the enterprise arising from the hazard with no modifi cations, and comparing this to the specifi ed tolerable risk for that hazard. For instance, if the expected rate of a high-pressure event in a steam system is once every two months, and the tolerable frequency of a pressure-related system failure is once in 200 years (or a 10 per cent chance of a pressure failure over the expected life of 20 years) the protective system can be expected to work 1,200 times. The failure rate must be better than 1 in 1,200, or less than This is a PFD of and corresponds to SIL 3. Required failure rates can be evaluated quantitatively from calculations involving numerical assessments of severity and probability. However, these assessments often involve a lot of work using statistical data that are not suffi ciently well defi ned for this purpose. Failure rates of new and highly reliable equipment cannot be specifi ed with any degree of confi dence, and failure rates of installed equipment depend very much on maintenance routines, adverse factors in the environment, and the availability of suitably trained staff. A more useful approach to assess the system integrity requirements is based on a qualitative analysis. Figure 3 shows a chart from IEC that can be used to determine the required SIL for a protective function. There are four categories of consequence, ranging from C a (minor) to C d (major). Likewise, probabilities are ranked from W 1 (low) to W 3 (high). Other factors modify the requirements depending on the likelihood that people will be exposed to the hazardous event when it occurs, and the possibility that anyone so exposed might be able to avoid injury (because of a slow development or warning noises, for example). As published, the chart does not give any indication on what is regarded as minor or major consequences, or low or high probability. To use these scales, they must be calibrated to match conditions in the target environment. Generally, low probability is a situation arising only once or twice during the expected life of a project, while high can be expected several hundred times. Minor consequences in a physical safety application may be injury to one person resulting in less than one day of lost time, while major may involve several fatalities. The calibration of these charts has to be decided by the customer organisation in line with the overall tolerable risk designation for the activity. Similar charts may be drawn up for other sets of consequences. The diagram below shows possible arrangements for charts relating to production loss and environmental damage, together with possible details for the calibrations. A qualitative assessment of integrity requirements may be made using these charts as a guide to stimulate group discussion. A suitable group might consist of members of the project team, and representatives of the client organisation and end-users. By identifying each hazard in turn, and then evaluating the consequences, the SIL for each component of risk can be identifi ed required SIL is the highest of those fi gures. So, if safety considerations result in SIL 2, production losses SIL 3, and environment SIL 1, the system must meet SIL 3. In the context of the effectiveness-case, the SIL provides a reference that can be used to identify relevant techniques for different phases of the development or design activity. Strategies can then demonstrate that the techniques are in line with an accepted industry standard such as IEC Meeting SIL Requirements What is the impact of the SIL on the design process? IEC sets out acceptable procedures that will allow the required integrity level to be met if implemented properly. Software 11
14 FIGURE 3: IEC RISK ANALYSIS PROCEDURE FIGURE 4: ENVIRONMENTAL AND PRODUCTION LOSSES 12
15 elements are covered in Part 3 of the Standard these are further expanded in Part 7. As an example, Table A.3 in Part 3 deals with software design and development tools as well as programming language. The requirements for suitable programming languages are set out in Section C.4.6 of Part 7 of the standard, and recommendations relating to specifi c programming languages are given in Table C.1 of this Part. The levels of recommendation are: HR Highly recommended if this technique or measure is not used, the reasons for not using it should be detailed during safety planning. R Recommended as a lower measure to an HR recommendation. The technique has no recommendation for or against its use. NR The technique or measure is positively not recommended for this safety integrity level if it is used, the reasons for using it should be detailed during safety planning. From Table A3, use of a suitable programming language is highly recommended for all SIL levels. Use of a restricted subset of the language is not required for SIL 1 and SIL 2, but is highly recommended for SIL 3 and SIL 4. Tools and translators must be certifi ed or have demonstrated reliability through extended use. While standard C and PL/M are acceptable for use at SIL 1, they are not recommended for SIL 3 or SIL 4. However, provided a restricted subset is used, with defi ned coding standards and static analysis tools, C is acceptable for the higher integrity levels. These are some of the recommendations given by IEC Others relate to the need for independent testing and inspection of code, competency requirements for people working on the project, defi nition of responsibilities for various activities within a project, and factors such as project communications, documentation and control. Those working on software projects with a requirement for high integrity are strongly advised to make themselves familiar with the full set of recommendations. TABLE A.3 SOFTWARE DESIGN AND DEVELOPMENT: SUPPORT TOOLS AND PROGRAMMING LANGUAGE (SEE 7.4.4) Technique/ Measure Ref SIL1 SIL2 SIL3 SIL4 1 Suitable programming language C.4.6 HR HR HR HR 2 Strongly typed programming language C.4.1 HR HR HR HR 3 Language subset C.4.2 HR HR 4a Certifi cated tools C.4.3 R HR HR HR 4b Tools: increased confi dence from use C.4.4 HR HR HR HR 5a Certifi cated translator C.4.3 R HR HR HR 5b Translator: increased confi dence from use C.4.4 HR HR HR HR 6 Library of trusted/verifi ed software modules and components C.4.5 R HR HR HR *Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/measures are indicated by a letter following the number. Only one of the alternate or equivalent techniques/measures has to be satisfi ed. (extracted from IEC , 1st edition, 1998) 13
16 TABLE C.1 RECOMMENDATIONS FOR SPECIFIC PROGRAMMING LANGUAGES Programming Language SIL1 SIL2 SIL3 SIL4 1 ADA HR HR R R 2 ADA with subset HR HR HR HR 3 MODULA-2 HR HR R R 4 MODULA-2 with subset HR HR HR HR 5 PASCAL HR HR R R 6 PASCAL with subset HR HR HR HR 7 FORTRAN 77 R R R R 8 FORTRAN 77 with subset HR HR HR HR 9 C R NR NR 10 C with subset and coding standard, and use of static analysis tools HR HR HR HR 11 PL/M R NR NR 12 PL/M with subset and coding standard HR R R R 13 Assembler R R Assembler with subset and coding standard R R R R 15 Ladder diagrams R R R R 16 Ladder diagrams with defi ned subset of language HR HR HR HR 17 Functional block diagram R R R R 18 Functional block diagram with defi ned subset of language HR HR HR HR 19 Structured text R R R R 20 Structured text with defi ned subset of language HR HR HR HR 21 Sequential function chart R R R R 22 Sequential function chart with defi ned subset of language HR HR HR HR 23 Instruction list R R R R 24 Instruction list with defi ned subset of language HR HR HR HR (extracted from IEC , 1st edition, 2000) 14
17 SUMMARY Engineering projects involving software components, or projects involving only software, involve risks similar to those found in hardware-oriented engineering activities. Where these risks cannot be reduced by other measures, the engineering processes used during the development and design phases must be suitable to ensure that the system will operate with the required degree of integrity. High-integrity may be required to ensure personnel safety, or to minimise exposure to fi nancial risk or other risk areas. The risk management process starts with identifying hazards and assessing the associated risk, involving the probability of a hazardous event and the severity or cost of the consequences. Where risks are excessive, they can be reduced either by reducing the probability of a hazardous event or by adding measures to reduce the severity. In either case, evidence must be produced to show that the measures effectively meet the target risk levels. Additional equipment (involving hardware and/ or software) must be of suffi cient integrity to provide confi dence that it will function as and when required. Risk management requires the development of a case showing that the developed system meets the specifi ed integrity requirements, which may involve reliability as well as safety issues. This case should include evidence related to the integrity, as well as an argument setting out how the evidence demonstrates effectiveness. A suitable format for this is Goal Structuring Notation. For software systems, integrity cannot be guaranteed simply through statistical failure rates. Most software failures are systematic or functional rather than random, and can be avoided only by adopting appropriate measures during design and development. Suitable measures for safety-related systems are set out in IEC While this is concerned with safetyrelated systems, its recommendations can be extended to cover other risk areas. ACKNOWLEDGEMENTS These guidelines were prepared by Bruce Durdle, based on notes for a course introducing the basic concepts of IEC Comments on these notes were made by Dr E Scharpf and C Feltoe. A number of people have commented on or reviewed this document. They include: D A Hall A Holt C Skinner J Moore B MacDonald P Voldner T McBride A Clark REFERENCES Health and Safety Executive 2001, Reducing Risks, Protecting People, United Kingdon Government, London. Retrieved from Howard et al 2005, 19 Deadly Sins of Software Security, McGraw-Hill, New York. International Electrotechnical Commission , Functional safety of electrical/electronic/programmable electronic safety-related systems, IEC parts 1-7. Kelly, T 1998, Arguing safety A systematic approach to managing safety cases, PhD Thesis, Department of Computer Science, University of York. Leveson, N G 1995, Safeware: system safety and computers, Addison-Wesley Professional. Leveson, N G 2002, Model-based analysis of socio-technical risk, Engineering Systems Division, Massachusetts Institute of Technology. Leveson, N G 2005, A systems-theoretic approach to safety in software-intensive systems, IEEE Transactions on Dependable and Secure Computing, 1(1), p Standards New Zealand 2004, New Zealand standard: Risk management, AS/NZS 4360:2004. Timms, C R 2006, Achieving ALARP with safety instrumented systems, The First Institution of Engineering and Technology International Conference on System Safety, p8. 15
18 APPENDIX 1: CRITICAL SOFTWARE SYSTEMS RISK ASSESSMENT CHECKLISTS These lists show items that may need to be considered during a risk assessment exercise. They are not specifi c recommendations, but form a base to develop the specifi c needs of each individual project. In particular, the items listed may or may not be relevant, and further entries will be needed to meet the requirements of a specifi c case. Checklists can summarise vital information for a project development team, and can also record issues that arise during a project for future reference either by the end-user or during later development exercises. They can also be used to record common data for use throughout the project. 1. CONTEXT The items on the left of this table are issues to consider during the initial concept development. Any requirement for the item should be indicated under the Required column, while the Specifi ed column should contain a reference to this issue in the User Requirements documents. Required Specified User capabilities application experience computer literacy physical requirements 1 Access physical internet controls Operating system Number of users normal peak Interfacing Hardware requirements For example, colour blindness. 2 Is there a need to use a specifi c platform or special hardware features? For example, many industrial software packages rely on the availability of a standard RS232 serial port to interconnect to target hardware users of these packages are seriously inconvenienced by the absence of such ports on modern laptops.
19 2. CRITICAL OBJECTIVES This section identifi es and records the primary objectives for the project. It also allows space for the tolerable failure rates for each objective to be set down. Sections such as Physical safety and Legislative will generally need to be expanded further to identify particular areas of concern. Target Tolerable Failure Rate Performance response time accuracy availability Physical safety Legislative Environmental Economic 3 Timing 4 Community acceptance public relations 3 Project budget limitations as well as required economic returns need to be considered. 4 Failure to meet deadlines for delivery of the design may have major consequences. 17
20 3. HAZARDS The Hazards checklist provides an opportunity to identify the particular issues that might arise from failure of the system to operate as intended. The Possible column should be used to indicate whether or not a particular item is an issue if it is, assessment is needed to determine how often it might arise. The SIL column allows the results of an integrity review to be recorded alongside the relevant hazard. Again, some of the item entries may need to be expanded to give fi ner detail, and the item list should be treated as an example only some items may be irrelevant while others may need to be added. Possible Frequency SIL Data entry maximum item length out of range timeout Associated equipment failure Unauthorised access physical electronic Other software 5 Misuse 18 5 DLL Hell is an example where loading a later version of software can impact on the operation of programs already installed.
21 4. CONSEQUENCES This list summarises possible areas where failure could result in a cost to the user or developer. It provides an indication of the areas of concern, and a basis for assessing the relative costs associated with each area. Assessment Method Cost Service to users degraded halted Health and safety Environmental Economic Legal Public relations 19
22 20
23 21
24 22 For more information, contact: ID= 573 <CLASSDEF NAME= AFII10020 /> GLYPH= GLYPH1061 <CLASSDEF YPHID <G GLYPH= AFII62841 ID= 856 NAME= AFII63896 /> ID= 574 <CLASSDEF NAME= AFII10021 /> GLYPH= GLYPH1062 ID= 620 NAME= A <G << ID= 743 <CLASSDEF NAME= ALEFLAMED /> GLYPH= AFII62843 ID= 857 NAME= AFII63897 /> ID= 575 ID= 621 NAME= A NAME= AFII10022 /> ID= 1257 NAME= UHOOKABOVE /> ID= 744 <CLASSDEF NAME= ZEROWIDTHNONJOINER /> <G GLYPH= AFII62844 ID= 858 NAME= AFII63898 /> ID= 576 ID= 622 NAME= A NAME= AFII10024 /> ID= 1258 NAME= UHORNACUTE /> <G < ID= 745 <CLASSDEF NAME= ZEROWIDTHJOINER /> GLYPH= AFII62845 ID= 859 NAME= AFII63899 /> ID= 577 ID= 623 NAME= A NAME= AFII10025 /> ID= 1259 NAME= UHORNACUTE /> <G < ID= 746 <CLASSDEF NAME= LEFTTORIGHTMARK /> GLYPH= AFII62881 ID= 860 NAME= AFII63900 /> ID= 578 ID= 624 NAME= A NAME= AFII10026 /> ID= 1260 NAME= UHORNGRAVE /> <G < ID= 747 <CLASSDEF NAME= RIGHTTOLEFTMARK /> GLYPH= AFII ID= 861 NAME= AFII63901 /> ID= 579 ID= 625 NAME= A NAME= AFII10027 /> ID= 1261 <EBLC> <EBDT> NAME= UHORNGRAVE /> <G < ID= 748 <CLASSDEF NAME= AFII57388 /> GLYPH= AFII ID= 862 NAME= AFII63902 /> ID= 580 ID= 626 NAME= A NAME= AFII10028 /> ID= <HEXDATA> E <HEXDATA> 303C0603 NAME= UHORNHOOKABOVE /> <G < ID= 749 <CLASSDEF 55040B13 NAME= AFII57403 /> GLYPH= AFII ID= 863 NAME= AFII63903 /> ID= 581 ID= 627 NAME= A NAME= AFII10029 /> ID= C NAME= UHORNHOOKABOVE /> <G < ID= 750 <CLASSDEF C NAME= AFII57407 /> GLYPH= AFII A ID= 864 NAME= AFII63904 /> ID= 582 ID= 628 NAME= A NAME= AFII10030 /> ID= D204D F73 NAME= UHORNTILDE /> <G < ID= 751 <CLASSDEF F NAME= AFII57409 /> GLYPH= AFII A ID= 865 NAME= AFII63905 /> ID= 583 ID= 629 NAME= A NAME= AFII10031 /> ID= F FF C NAME= UHORNTILDE /> <G < ID= 752 <CLASSDEF NAME= AFII57440 /> GLYPH= AFII D75C ID= 866 NAME= AFII63906 /> ID= 584 ID= 630 NAME= A NAME= AFII10032 /> ID= F6E B NAME= UHORNDOTBELOW /> <G < ID= 753 <CLASSDEF 0480C NAME= AFII57451 /> GLYPH= AFII C ID= 867 NAME= AFII63908 /> ID= 585 ID= 631 NAME= A NAME= AFII10033 /> ID= NAME= UHORNDOTBELOW /> ID= 632 NAME= A <G < ID= 754 <CLASSDEF 045A5A5A A NAME= AFII57452 /> GLYPH= AFII C3 0C ID= 868 NAME= AFII63910 /> ID= 586 NAME= AFII10034 /> ID= E 04FE F6E E NAME= YDOTBELOW /> ID= 633 NAME= A <G < ID= 755 <CLASSDEF 06045A5A A5A0804 NAME= AFII57453 /> GLYPH= AFII F 5F5F5F89 ID= 869 NAME= AFII63912 /> ID= 587 NAME= AFII10035 /> ID= D6F E64311E NAME= YDOTBELOW /> ID= 634 NAME= A <G < ID= 756 <CLASSDEF C0603 AAAAAAAA NAME= AFII57454 /> GLYPH= AFII AA2FCBF2 FCBF8922 ID= 870 NAME= AFII62927 /> ID= 588 NAME= AFII10036 /> ID= D F736F NAME= YHOOKABOVE /> ID= 635 NAME= A <G < ID= 757 <CLASSDEF AAAA NAME= AFII57455 /> GLYPH= AFII AAAAAAAA AAA057D5 ID= 871 NAME= AFII63941 /> ID= 589 NAME= AFII10037 /> ID= F72706F 05FE F6E311E F57D5F D5F00B NAME= YHOOKABOVE /> ID= 872 NAME= AFII62939 /> ID= 636 NAME= A <G < ID= ID= 758 NAME= EBREVE /> <CLASSDEF 301C0603 NAME= AFII57456 /> GLYPH= AFII62884 ID= 590 NAME= AFII10038 /> ID= B14 154D F736F 900C B A A56A56A 56A56A0C NAME= YTILDE /> ID= 873 NAME= AFII63943 /> ID= 637 NAME= A <G < ID= ID= 759 NAME= EBREVE /> <CLASSDEF NAME= AFII57457 /> GLYPH= AFII ID= 591 NAME= AFII10039 /> ID= F72706F F6E F57F F57F57F5 7F5402A8 NAME= YTILDE /> ID= 874 NAME= AFII62943 /> ID= 638 NAME= A <G < ID= FE0000 ID= 760 NAME= EDOT /> <CLASSDEF 9D300D06 NAME= AFII57458 /> GLYPH= AFII ID= 592 NAME= AFII10040 /> ID= A F70D A A NAME= UNI01CD /> ID= 875 NAME= AFII62946 /> ID= 639 NAME= A <G < ID= ID= 761 NAME= EDOT /> <CLASSDEF 03818B00 NAME= AFII57392 /> GLYPH= AFII ID= 593 NAME= AFII10041 /> ID= D E9FFBE C C FD57F55F D57F55FD NAME= UNI01CE /> ID= 876 NAME= AFII63946 /> ID= 640 NAME= A <G < ID= ID= 762 NAME= GCIRCUMFLEX /> <CLASSDEF NAME= AFII57393 /> GLYPH= AFII62885 ID= 594 NAME= AFII10042 /> ID= ACAB BBC A21AA1 57F55FC D07000B NAME= UNI01CF /> ID= 877 NAME= AFII62951 /> ID= 641 NAME= A <G < ID= FE0000 ID= 763 NAME= GCIRCUMFLEX /> <CLASSDEF FDAB4446 NAME= AFII57394 /> GLYPH= AFII ID= 595 NAME= AFII10043 /> ID= 1277 E312DC33 9B61D1B BC67400C F B0754AA AAAAAAAA NAME= UNI01D0 /> ID= 878 NAME= AFII63948 /> ID= 642 NAME= A <G < <CLASSDEF ID= ID= 764 GLYPH= AFII NAME= GDOT /> <CLASSDEF 3C5077B8 NAME= AFII57395 /> GLYPH= AFII AAAAAAAA E4 AAAAAA80 ID= 596 NAME= AFII10044 /> ID= 1278 B30EEEB9 A70F B5EEC C 0F07000B 072A57F9 NAME= UNI01D1 /> ID= 879 NAME= AFII62953 /> ID= 643 NAME= A <G < <CLASSDEF ID= ID= 765 GLYPH= AFII NAME= GDOT /> <CLASSDEF 24F8B39D NAME= AFII57396 /> GLYPH= AFII FE57F FE57F95F ID= 597 NAME= AFII10045 /> ID= E4F F ECE E57F C08 NAME= UNI01D2 /> ID= 880 NAME= AFII63950 /> ID= 644 NAME= A <G < <CLASSDEF ID= FD0000 ID= 766 GLYPH= AFII NAME= GCEDILLA /> <CLASSDEF 32F37380 NAME= AFII57397 /> GLYPH= AFII C C423 ID= 598 NAME= AFII10046 /> ID= BDFBB FA14C027 74C31F8F C C41008 NAME= UNI01D3 /> ID= 881 NAME= AFII63951 /> ID= 645 NAME= A <G < <CLASSDEF ID= ID= 767 GLYPH= AFII57494 NAME= GCEDILLA /> <CLASSDEF 11D1A8C4 NAME= AFII57398 /> GLYPH= AFII C AA55AA55 ID= 599 NAME= AFII10047 /> ID= C482D5D B2393E AD8C AA55AA55 AA55AA55 NAME= UNI01D4 /> ID= 882 NAME= AFII63952 /> ID= 646 NAME= A <G < <CLASSDEF ID= ID= 768 GLYPH= AFII NAME= HCIRCUMFLEX /> <CLASSDEF DCD05951 NAME= AFII57399 /> GLYPH= AFII AA55AA C08 ID= 600 NAME= AFII10048 /> ID= 1282 A96DC B6E A95D106E FF55FF 55FF55FF NAME= UNI01D5 /> ID= 883 NAME= AFII63953 /> ID= 647 NAME= A <G < <CLASSDEF ID= FD0000 ID= 769 GLYPH= AFII NAME= HCIRCUMFLEX /> <CLASSDEF FC3A09A8 NAME= AFII57400 /> GLYPH= AFII FF55FF FF55FF ID= 601 NAME= AFII10049 /> ID= 1283 EB3B8351 5D4EAB A D C NAME= UNI01D6 /> ID= 884 NAME= AFII63956 /> ID= 648 NAME= A <G < <CLASSDEF ID= ID= 770 GLYPH= AFII NAME= HBAR /> <CLASSDEF 075A3082 NAME= AFII57401 /> GLYPH= AFII A0A C C42 ID= 602 NAME= AFII10065 /> ID= D C 3108C D NAME= UNI01D7 /> ID= 885 NAME= AFII63958 /> ID= 649 NAME= A <G < <CLASSDEF ID= ID= 771 GLYPH= AFII57504 NAME= HBAR /> <CLASSDEF 00300B06 NAME= AFII57381 /> GLYPH= AFII AA55 0B AA55AA55 ID= 603 NAME= AFII10066 /> ID= D0F A AA55AA55 AA55AA55 NAME= UNI01D8 /> ID= 886 NAME= AFII63959 /> ID= 650 NAME= A <G < <CLASSDEF ID= 428 0BFD0000 ID= 772 GLYPH= AFII NAME= ITILDE /> <CLASSDEF NAME= AFII57461 /> GLYPH= AFII B AA D0855 ID= 604 NAME= AFII10067 /> ID= D C B FF55FF 55FF55FF NAME= UNI01D9 /> ID= 887 NAME= AFII63960 /> ID= 651 NAME= A <G < <CLASSDEF ID= ID= 773 GLYPH= AFII NAME= ITILDE /> <CLASSDEF E4D143FD NAME= AFII63167 /> GLYPH= AFII B0B FF55FF FF55FF ID= 605 NAME= AFII10068 /> ID= F338 CC6E3BF2 0B82A NAME= UNI01DA /> ID= 888 NAME= AFII63961 /> ID= 652 NAME= P <G < <CLASSDEF ID= ID= 774 GLYPH= AFII NAME= IMACRON /> <CLASSDEF NAME= AFII57459 /> GLYPH= AFII B ID= F E NAME= UNI01DB /> ID= 889 NAME= AFII64046 /> ID= 653 NAME= S <G < <CLASSDEF ID= 431 0BFC0000 ID= 775 GLYPH= AFII57505 NAME= IMACRON /> <CLASSDEF 65726E65 NAME= AFII57543 /> GLYPH= AFII B ID= A130E NAME= UNI01DC /> ID= 890 NAME= AFII64058 /> ID= 654 NAME= H <G < <CLASSDEF ID= ID= 776 GLYPH= AFII57506 NAME= IBREVE /> <CLASSDEF NAME= AFII57534 /> GLYPH= AFII C0C0101 2A957FE C 5FF957FE ID= E 2C20496E 632E FF957F E55FF957 NAME=.NOTDEF#8 /> ID= 891 NAME= AFII64059 /> ID= 655 NAME= H <G < <CLASSDEF ID= ID= 777 GLYPH= AFII57507 NAME= IBREVE /> <CLASSDEF NAME= AFII57494 /> GLYPH= AFII FE55FF80 0C D ID= B13 2A A NAME=.NOTDEF#9 /> ID= 892 NAME= AFII64060 /> ID= 656 NAME= H <G < <CLASSDEF ID= 434 0CFC0000 ID= 778 GLYPH= AFII57508 NAME= IOGONEK /> <CLASSDEF 6E20436F NAME= AFII62843 /> GLYPH= AFII C ID= D6D C 20536F A NAME=.NOTDEF#10 /> ID= 893 NAME= AFII64061 /> ID= 657 NAME= H <G < <CLASSDEF ID= ID= 779 GLYPH= AFII57509 NAME= IOGONEK /> <CLASSDEF NAME= AFII62844 /> GLYPH= AFII D0D D0AAA AA955 ID= C AA955AA9 55AA955A NAME=.NOTDEF#11 /> ID= 894 NAME= AFII62945 /> ID= 658 NAME= T <G < <CLASSDEF ID= ID= 780 GLYPH= AFII57534 NAME= JCIRCUMFLEX /> <CLASSDEF NAME= AFII62845 /> GLYPH= AFII A955AA95 0D AA955AA ID= C78F 37DB9228 DF3CBB1A A 000D0A55 NAME= UNI0492 /> ID= 895 NAME= AFII64184 /> ID= 659 NAME= S <G < <CLASSDEF ID= 437 0DFC0000 ID= 781 GLYPH= AFII57543 NAME= JCIRCUMFLEX /> <CLASSDEF AD82FA67 NAME= AFII64240 /> GLYPH= AFII D FF557FF FF557 ID= D FF FF557FF5 57FF557F NAME= UNI0493 /> ID= 896 NAME= AFII52399 /> ID= 660 NAME= P <G < <CLASSDEF ID= ID= 782 GLYPH= AFII NAME= KCEDILLA /> <CLASSDEF NAME= AFII64241 /> GLYPH= AFII E0E0101 F557FF C 7FF01409 ID= E300C06 0A2B C 010F0A NAME= UNI0496 /> ID= 897 NAME= AFII52400 /> ID= 661 NAME= Q <G < <CLASSDEF ID= ID= 783 GLYPH= AFII NAME= KCEDILLA /> <CLASSDEF NAME= AFII63954 /> GLYPH= AFII C ID= D D0A NAME= UNI0497 /> ID= 898 NAME= AFII62753 /> ID= 662 NAME= H <G < <CLASSDEF ID= 440 0CFB0000 ID= 784 GLYPH= AFII NAME= KGREENLANDIC /> <CLASSDEF NAME= AFII57382 /> GLYPH= AFII C A F0A55 ID= A2B AA556AA 556AA556 NAME= UNI049A /> ID= 899 NAME= AFII57411 /> ID= 663 NAME= Q <G < <CLASSDEF ID= ID= 785 GLYPH= AFII57555 NAME= LCEDILLA /> <CLASSDEF NAME= AFII64242 /> GLYPH= AFII F0F0101 AA556AA AA556A ID= A01 01FF A556AA55 6AA556AA NAME= UNI049B /> ID= 900 NAME= AFII62754 /> ID= 664 NAME= D <G < <CLASSDEF ID= ID= 786 GLYPH= AFII57567 NAME= LCEDILLA /> <CLASSDEF 041FA029 NAME= AFII62881 /> GLYPH= AFII A000F 0D050A00 0A557FF5 ID= A 2F2F FF557F F557FF55 NAME= UNI049C /> ID= 901 NAME= AFII57412 /> ID= 665 NAME= M <G < <CLASSDEF 0DFB0000 ID= 787 GLYPH= AFII62753 <CLASSDEF 772E7665 NAME= AFII57504 /> GLYPH= AFII D FF557FF FF557 ID= E2E63 6F6D2F FF557FF5 57FF8884 NAME= UNI049D /> ID= 902 NAME= AFII62755 /> ID= 666 NAME= M <G < <CLASSDEF ID= 788 GLYPH= AFII62754 <CLASSDEF 65706F73 NAME= AFII57369 /> GLYPH= AFII B ID= F72 792F A NAME= UNI04A2 /> ID= 903 NAME= AFII57413 /> ID= 667 NAME= R <G < <CLASSDEF ID= 789 GLYPH= AFII62755 <CLASSDEF B NAME= AFII57370 /> GLYPH= AFII F050A ID= 1303 B NAME= UNI04A3 /> ID= 904 NAME= AFII62756 /> ID= 668 NAME= P <G < <CLASSDEF 0FFB0000 ID= 790 GLYPH= AFII62756 <CLASSDEF NAME= AFII57371 /> GLYPH= AFII F ID= E 636F7270 6F NAME= UNI04AE /> ID= 905 NAME= AFII57414 /> ID= 669 NAME= S <G < <CLASSDEF ID= 791 GLYPH= AFII62757 <CLASSDEF NAME= AFII57372 /> GLYPH= AFII C ABF ID= E63652C C FCAAFFF2 ABFFCAAF NAME= UNI04AF /> ID= 906 NAME= AFII62759 /> ID= 670 NAME= S <G < <CLASSDEF ID= 792 GLYPH= AFII62758 <CLASSDEF 20616E64 NAME= AFII57373 /> GLYPH= AFII FF2ABFFC 0F050B00 AAFFF2AB ID= FFCAAFFF 2ABFFCAA NAME= UNI04B0 /> ID= 907 NAME= AFII62757 /> ID= 671 NAME= S <G < <CLASSDEF 0FFB0000 ID= 793 GLYPH= AFII62759 <CLASSDEF NAME= AFII57374 /> GLYPH= AFII F FFF ID= C79 0A A NAME= UNI04B1 /> ID= 908 NAME= AFII62758 /> ID= 672 NAME= A <G < <CLASSDEF ID= 794 GLYPH= AFII62760 <CLASSDEF 20746F2C NAME= AFII57375 /> GLYPH= AFII E ID= C NAME= UNI04B2 /> ID= 909 NAME= AFII57415 /> ID= 673 NAME= B <G < 54696D65 <CLASSDEF ID= 795 GLYPH= AFII D70696E <CLASSDEF 6E NAME= AFII57391 /> 0E060B GLYPH= AFII ID= F6E NAME= UNI04B3 /> ID= 910 NAME= AFII62760 /> ID= 674 NAME= G <G < <CLASSDEF 0EFA F ID= 796 GLYPH= AFII E F <CLASSDEF NAME= AFII57471 /> GLYPH= AFII ID= D ABF FCAAFFF2 NAME= UNI04B8 /> ID= 911 NAME= AFII57416 /> ID= 675 NAME= D <G < 55040B13 <CLASSDEF B4E4F20 ID= 797 GLYPH= AFII C <CLASSDEF 6E ABFFCAAF NAME= AFII57460 /> C4954 GLYPH= AFII63759 FF2ABFFC ID= A F6E AAFFF2AB FFCAAFFF NAME= UNI04B9 /> ID= 912 NAME= AFII62763 /> ID= 676 NAME= H <G < <CLASSDEF ID= 798 GLYPH= AFII C20 <CLASSDEF 20312E30 2ABFFCAA NAME= AFII52258 /> 10060C GLYPH= AFII63761 FFF0150A ID= C C61 626C C NAME= UNI04BA /> ID= 913 NAME= AFII62761 /> ID= 677 NAME= V <G < <CLASSDEF 10FA ID= 799 GLYPH= AFII E2C20 <CLASSDEF 696E NAME= AFII57506 /> E632E GLYPH= AFII ID= E NAME= UNI04BB /> ID= 914 NAME= AFII62762 /> ID= 678 NAME= Z <G < 301E170D <CLASSDEF ID= 800 GLYPH= AFII <CLASSDEF F NAME= AFII62958 /> GLYPH= AFII C ID= F A0A C 00100C55 5AAA555A NAME= UNI018F /> ID= 915 NAME= AFII57417 /> ID= 679 NAME= H <G < 5A170D30 <CLASSDEF ID= 801 GLYPH= AFII <CLASSDEF AA555AAA NAME= AFII62956 /> 11060D A GLYPH= AFII AAA55 ID= A2F2F E AAA555A AA555AAA NAME= UNI0259 /> ID= 916 NAME= AFII62764 /> ID= 680 NAME= T <G < 3081B231 <CLASSDEF 11FA ID= 802 GLYPH= AFII A <CLASSDEF 69676E2E 555AAA55 NAME= AFII52957 /> E5665 GLYPH= AFII AAA555A ID= F6D3B D6D AA555AAA 160C0010 NAME= UNI04E8 /> ID= 917 NAME= AFII57418 /> ID= 681 NAME= Y <G < <CLASSDEF E2C20 ID= 803 GLYPH= AFII E632E <CLASSDEF 696C2061 0C555FFF NAME= AFII57505 /> F301D GLYPH= AFII FFF55 5FFF555F ID= D FF555FFF NAME= UNI04E9 /> ID= 918 NAME= AFII62767 /> ID= 682 NAME= F <G < <CLASSDEF B ID= 804 GLYPH= AFII <CLASSDEF FFF55 NAME= AFII62889 /> E20 GLYPH= AFII FFF555F </GLYPHORDER> E2E 636F6D3B 000C0012 FF555FFF 555FFF55 ID= 919 NAME= AFII62765 /> ID= 683 NAME= K <G < <CLASSDEF E65 ID= 805 GLYPH= AFII F72 <CLASSDEF 206F720A 5FFF8889 NAME= AFII62887 /> B GLYPH= AFII D 61696C ID= 920 NAME= AFII62766 /> ID= 684 NAME= L <G < <CLASSDEF B133D ID= 806 GLYPH= AFII E E <CLASSDEF NAME= AFII62888 /> GLYPH= AFII <DSIG> 69676E2C 20496E63 2E2C ID= 921 NAME= AFII57419 /> ID= 685 NAME= F <G < E <CLASSDEF E636F6D ID= 807 GLYPH= AFII C 2F <CLASSDEF NAME= AFII57507 /> F GLYPH= AFII <!-- NOTE THAT 436F E2C THE DIGITAL SIGNATURE ID= 922 WILL BE NAME= AFII62770 /> INVALID AFTER ID= 686 RECOMPILATI NAME= M <G < 6F72792F <CLASSDEF ID= 808 GLYPH= AFII E636F <CLASSDEF 4D6F756E NAME= AFII62961 /> E20 GLYPH= AFII <HEXDATA> E C ID= 923 NAME= AFII62768 /> ID= 687 NAME= F <G < <CLASSDEF E2C ID= 809 GLYPH= AFII A 4C <CLASSDEF NAME= AFII62959 /> E4C5444 GLYPH= AFII A F AA ID= 924 NAME= AFII62769 /> ID= 688 NAME= N <G < <CLASSDEF E30 ID= 810 GLYPH= AFII F 2C <CLASSDEF FFE55 NAME= AFII62960 /> GLYPH= AFII FFF FFE555FF F9557FFE B ID= 925 NAME= AFII57420 /> ID= 689 NAME= S <G < <CLASSDEF 05FEFC E ID= 811 GLYPH= AFII D <CLASSDEF FFF95 NAME= AFII57508 /> GLYPH= AFII FFE A86 FFF9557F 4886F70D 676E2C20 496E632E C FE555FFF A ID= 926 NAME= AFII62773 /> ID= 690 NAME= A <G < 616D7069 <CLASSDEF E 6E ID= 812 GLYPH= AFII <CLASSDEF 6C FFE0 NAME= AFII62962 /> 0C GLYPH= AFII FEFA E C0608 2A ID= 927 NAME= AFII62771 /> ID= 691 NAME= F <G < <CLASSDEF ID= 813 GLYPH= AFII D06 <CLASSDEF 642E2043 </HEXDATA> NAME= AFII57567 /> A8648 GLYPH= AFII F70D E0A A2B ID= 928 NAME= AFII62772 /> ID= 692 NAME= P <G < 86F70D01 <CLASSDEF B ID= 814 GLYPH= AFII F <CLASSDEF 4E </EBDT> NAME= AFII62964 /> GLYPH= AFII A C41 494D C060A 2B ID= 929 NAME= AFII57421 /> ID= 693 NAME= F <G < 0A <CLASSDEF D498 ID= 815 GLYPH= AFII AD E86792C1 <CLASSDEF 20414E44 NAME= AFII52305 /> D 6D11B3AA GLYPH= AFII E07000B CA21E 204C C C 801C003C 003C003C ID= 930 NAME= AFII62776 /> ID= 694 NAME= T <G < F8A7CFC8 <CLASSDEF 07FDF900 2A32C6EA ID= 816 GLYPH= AFII F2CC2CA6 <CLASSDEF 494D4954 NAME= AFII52306 /> D2059F1A GLYPH= AFII F F 45442E0A 0A E494E47 006C ID= 931 NAME= AFII62774 /> ID= 695 NAME= Q <G < 7FA0E7BE <CLASSDEF D4 2F4F5FE0 ID= 817 GLYPH= AFII62783 GLYPH= AFII D01BB872 <CLASSDEF 3A NAME= AFII57509 /> CFA945 GLYPH= AFII E003E 003E F C0608 2A ID= 932 NAME= AFII62775 /> ID= 696 NAME= R <G < 1341EC19 <CLASSDEF FC340CB ID= 818 GLYPH= AFII62784 GLYPH= AFII E6112D <CLASSDEF NAME= AFII62967 /> B 8F964D62 GLYPH= AFII F70D DAE11E8F FB7550D3 ID= 933 NAME= AFII57422 /> ID= 697 NAME= S <G < 97A5AF1C <CLASSDEF D 062F3305 ID= 819 GLYPH= AFII62785 GLYPH= AFII D440A5DD <CLASSDEF NAME= AFII62965 /> D1AD5B0 GLYPH= AFII A F C A4543 A08210CF ID= 934 NAME= AFII62779 /> ID= 698 NAME= T <G < F4B8036D <CLASSDEF D586FB4F ID= 820 GLYPH= AFII62786 GLYPH= AFII D65F1049 <CLASSDEF F NAME= AFII62966 /> 002A0040 DEB7E40A GLYPH= AFII A C A F37DB92 28DF3CBB ID= 935 NAME= AFII62777 /> ID= 699 NAME= D <G < 164E650C <CLASSDEF AC7 ID= 821 GLYPH= AFII62787 GLYPH= AFII FF9F9229 <CLASSDEF 4E NAME= AFII57555 /> B8137 GLYPH= AFII AAD82FA D F4E A F70D ID= 936 NAME= AFII62778 /> ID= 700 NAME= V <G < 9246D0B4 <CLASSDEF C 9B ID= 822 GLYPH= AFII62788 GLYPH= AFII FCF700 52CDF7B3 <CLASSDEF NAME= AFII52364 /> FB2CF76 GLYPH= AFII D F ID= 937 NAME= AFII57423 /> ID= 701 NAME= D <G < 0A <CLASSDEF B987CD ID= 823 GLYPH= AFII62789 GLYPH= AFII C4 C2DCB2CE <CLASSDEF 4E542E20 NAME= AFII63753 /> A 70B106E3 GLYPH= AFII E E E ID= 938 NAME= AFII62780 /> ID= 702 NAME= G <G < 62B2F511 <CLASSDEF AE84872 ID= 824 GLYPH= AFII62790 GLYPH= AFII C987B237 <CLASSDEF NAME= AFII63754 /> C6532C GLYPH= AFII A13 0E F A C E2C2049 ID= 939 NAME= AFII57424 /> ID= 703 NAME= G <G < B <CLASSDEF C BF8C4818 ID= 825 GLYPH= AFII62791 GLYPH= AFII A <CLASSDEF 41494D53 NAME= AFII63759 /> AFAC2C34 GLYPH= AFII E632E E 20494D B 132A5665 ID= 940 NAME= AFII62781 /> ID= 704 NAME= N <G < 83504E4A <CLASSDEF A308F62 ID= 826 GLYPH= AFII62792 GLYPH= AFII E A59E0215 <CLASSDEF 4C NAME= AFII63763 /> C 851EEA2B GLYPH= AFII B000F E E F6D6D ID= 941 NAME= AFII57425 /> ID= 705 NAME= V <G < EE <CLASSDEF 0BFBF ADE0D ID= 827 GLYPH= AFII62793 GLYPH= AFII CDF4 <CLASSDEF NAME= AFII63795 /> A5EFE6 GLYPH= AFII C20536F E C 20494E C69 ID= 942 NAME= AFII62782 /> ID= 706 NAME= F <G < 9EFCF1CB <CLASSDEF C2 F8D93293 ID= 828 GLYPH= AFII62794 GLYPH= AFII C 9F77F630 <CLASSDEF 4C NAME= AFII62891 /> 140B000E F2B98592 GLYPH= AFII BFBF E E E170D <CLASSDEF ID= 943 GLYPH= AFII57407 NAME= AFII57426 /> ID= 707 NAME= F <G < 52D7A049 <CLASSDEF EAE7B4 ID= 829 GLYPH= AFII62795 GLYPH= AFII EC28F <CLASSDEF 530A4F46 NAME= AFII63808 /> E6898D GLYPH= AFII D E A170D30 <CLASSDEF ID= 944 GLYPH= AFII57409 NAME= AFII62783 /> ID= 708 NAME= L <G < <CLASSDEF A ID= 830 GLYPH= AFII62796 GLYPH= AFII C 42F825EC <CLASSDEF 4C NAME= AFII62938 /> E71198FE GLYPH= AFII A 204F E <CLASSDEF 300F0603 ID= 945 GLYPH= AFII57410 NAME= AFII57427 /> ID= 709 NAME= L <G < 818F9888 <CLASSDEF B ID= 831 GLYPH= AFII62797 GLYPH= AFII A3 <CLASSDEF 464F5220 NAME= AFII63810 /> GLYPH= AFII D E C E65 <CLASSDEF ID= 946 GLYPH= AFII57411 NAME= AFII62786 /> ID= 710 NAME= A <G < <CLASSDEF 0DFAF D25 ID= 832 GLYPH= AFII62798 GLYPH= AFII C300A <CLASSDEF NAME= AFII62942 /> 06082B06 GLYPH= AFII A130E 504F5345 2C20414E <CLASSDEF E ID= 947 GLYPH= AFII57412 NAME= AFII62784 /> ID= 711 NAME= S <G < <CLASSDEF </HEXDATA> F ID= 833 GLYPH= AFII62799 GLYPH= AFII D <CLASSDEF 4C4C204E NAME= AFII62947 /> GLYPH= AFII C20496E 632E3133 4F540A C C <CLASSDEF 55040B13 ID= 948 GLYPH= AFII57413 NAME= AFII62785 /> ID= 712 NAME= S <G < </EBLC> <CLASSDEF 0B ID= 834 GLYPH= AFII62800 GLYPH= AFII F845 <CLASSDEF 20464F52 NAME= AFII63813 /> GLYPH= AFII A F4E E5449 6E20436F <CLASSDEF 6D6D6572 ID= 949 GLYPH= AFII57414 NAME= AFII57428 /> ID= 713 NAME= S <G < <CLASSDEF 06082B06 ID= 835 GLYPH= AFII62801 GLYPH= AFII <CLASSDEF 414C2C20 NAME= AFII63823 /> GLYPH= AFII C 20536F E C20414E <CLASSDEF ID= 950 GLYPH= AFII57415 NAME= AFII62789 /> ID= 714 NAME= S <G < <GDEF> <CLASSDEF 733A2F2F ID= 836 GLYPH= AFII62802 GLYPH= AFII E <CLASSDEF NAME= AFII63824 /> GLYPH= AFII C E204F <CLASSDEF 819F300D ID= 951 GLYPH= AFII57416 NAME= AFII62787 /> ID= 715 NAME= A <G < E <CLASSDEF <VERSION 2E636F6D ID= 837 GLYPH= AFII62803 VALUE= 1.0 /> GLYPH= AFII F <CLASSDEF 44414D41 NAME= AFII63833 /> 6F GLYPH= AFII A F70D E A <CLASSDEF D ID= 952 GLYPH= AFII57417 NAME= AFII62788 /> ID= 716 NAME= A <G < 6F72792F <CLASSDEF <GLYPHCLASSDEF ID= 838 GLYPH= AFII62804 GLYPH= AFII F <CLASSDEF FORMAT= 2 > NAME= AFII63844 /> 1D GLYPH= AFII F C53 C3D36965 <CLASSDEF ID= 953 GLYPH= AFII57418 NAME= AFII57429 /> ID= 717 NAME= A <G < <CLASSDEF <CLASSDEF FF ID= 839 GLYPH= AFII62805 GLYPH= AFII B0603 <CLASSDEF 2E0A0A43 GLYPH= AFII52258 NAME= AFII62882 /> 551D0F04 GLYPH= AFII63952 AB28C662 18B F6E7465 6E F C <CLASSDEF 4A3BC27E ID= 954 GLYPH= AFII57419 NAME= AFII62792 /> ID= 718 NAME= B <G < <CLASSDEF <CLASSDEF C0300D06 ID= 840 GLYPH= AFII62806 GLYPH= AFII A8648 <CLASSDEF GLYPH= AFII52305 NAME= AFII62883 /> 86F70D01 GLYPH= AFII63953 D8D3D7C DD E CF1169C <CLASSDEF CC6BA929 ID= 955 GLYPH= AFII57420 NAME= AFII62790 /> ID= 719 NAME= G <G < <CLASSDEF <CLASSDEF ID= 841 GLYPH= AFII62807 GLYPH= AFII CEA9DF3 <CLASSDEF GLYPH= AFII52306 NAME= AFII62884 /> A3 GLYPH= AFII63954 B28F C8C E 6F6E A63CED1E <CLASSDEF 0575F013 ID= 956 GLYPH= AFII57421 NAME= AFII62791 /> ID= 720 NAME= D <G < 21BADBF3 <CLASSDEF <CLASSDEF 86F37B58 ID= 842 GLYPH= AFII62808 GLYPH= AFII <CLASSDEF GLYPH= AFII52364 NAME= AFII62885 /> FAB24B6C GLYPH= AFII C144D D A BE <CLASSDEF B8624E31 ID= 957 GLYPH= AFII57422 NAME= AFII57430 /> ID= 721 NAME= H <G < 3FCC0721 <CLASSDEF <CLASSDEF 5ED7C335 ID= 843 GLYPH= AFII62809 GLYPH= AFII57454 CB9388F4 <CLASSDEF A GLYPH= AFII52399 NAME= AFII62886 /> 5143ED2D GLYPH= AFII ED1FCC9 0CEB7D E73696F 6E BFAEB447 <CLASSDEF 51EC6FCE ID= 958 GLYPH= AFII57423 NAME= AFII62795 /> ID= 722 NAME= V <G < A92CA171 <CLASSDEF <CLASSDEF C7C7B503 ID= 844 GLYPH= AFII62810 GLYPH= AFII E9C9 <CLASSDEF 6C GLYPH= AFII52400 NAME= AFII63846 /> 11FB2415 GLYPH= AFII D6 7D C 6C206E6F E28FD951 <CLASSDEF D7FB9719 ID= 959 GLYPH= AFII57424 NAME= AFII62793 /> ID= 723 NAME= Z <G < 8A73E2D9 <CLASSDEF <CLASSDEF 4CC347FB ID= 845 GLYPH= AFII62811 GLYPH= AFII C1E <CLASSDEF 20636F6E GLYPH= AFII52957 NAME= AFII63849 /> 003BEDEB GLYPH= AFII63960 BC3ED777 81C643DD F2DDDFCA <CLASSDEF A3838BCB ID= 960 GLYPH= AFII57425 NAME= AFII62794 /> ID= 724 NAME= T <G < A7954F60 <CLASSDEF <CLASSDEF ID= 846 GLYPH= AFII62812 GLYPH= AFII DE281B <CLASSDEF GLYPH= AFII57369 NAME= AFII63850 /> 72AE5F58 GLYPH= AFII C13D A E666F 726D <CLASSDEF 01300D06 ID= 961 GLYPH= AFII57426 NAME= AFII57431 /> ID= 725 NAME= Y <G < 8E11E4C0 <CLASSDEF <CLASSDEF 028B6955 ID= 847 GLYPH= AFII62813 GLYPH= AFII57455 B <CLASSDEF 696F6E0A GLYPH= AFII57370 NAME= AFII63851 /> AB18AF32 GLYPH= AFII A F70D C <CLASSDEF ID= 962 GLYPH= AFII57427 NAME= AFII62798 /> ID= 726 NAME= F <G < 50D45B3C <CLASSDEF <CLASSDEF 45F42B8C ID= 848 GLYPH= AFII62815 GLYPH= AFII CC <CLASSDEF GLYPH= AFII57371 NAME= AFII63852 /> C8A8A4A5 GLYPH= AFII64058 B5BCB075 6A89A E 0AA BD6478C3 <CLASSDEF A ID= 963 GLYPH= AFII57428 NAME= AFII62796 /> ID= 727 NAME= K <G < A518CC73 <CLASSDEF <CLASSDEF 4E ID= 849 GLYPH= AFII62816 GLYPH= AFII A9F <CLASSDEF 70733A2F GLYPH= AFII57372 NAME= AFII63855 /> 30820A08 GLYPH= AFII AA C 2F E E <CLASSDEF B9524A51 ID= 964 GLYPH= AFII57429 NAME= AFII62797 /> ID= 728 NAME= L <G < A <CLASSDEF <CLASSDEF ID= 850 GLYPH= AFII62817 GLYPH= AFII F28EF8A8 <CLASSDEF 6E2E636F GLYPH= AFII57373 NAME= AFII63856 /> FBEA6D11 GLYPH= AFII FE53 2D7BD531 6D2F F F7279 8CC56599 <CLASSDEF 41412FF2 ID= 965 GLYPH= AFII57430 NAME= AFII57432 /> ID= 729 NAME= M <G < <CLASSDEF <CLASSDEF 4B655C30 ID= 851 GLYPH= AFII62818 GLYPH= AFII D06092A <CLASSDEF 2F GLYPH= AFII57374 NAME= AFII63761 /> F7 GLYPH= AFII64061 AE637AE E6C6F67 6F2E6769 1A1F7A8B <CLASSDEF 41D08E3A ID= 966 GLYPH= AFII57431 NAME= AFII62801 /> ID= 730 NAME= N <G < 0D <CLASSDEF <CLASSDEF ID= 852 GLYPH= AFII62819 GLYPH= AFII F <CLASSDEF GLYPH= AFII57375 NAME= AFII63882 /> GLYPH= AFII64184 D0CD D075F8 1F D EA71C ID= 967 NAME= AFII62799 /> ID= 731 NAME= S <G < <CLASSDEF <CLASSDEF 6E ID= 853 GLYPH= AFII62820 GLYPH= AFII E <CLASSDEF GLYPH= AFII57381 NAME= AFII63825 /> GLYPH= AFII AAEC53E 32E621B8 020E A060B C093E1 C7385CD8 ID= 968 NAME= AFII62800 /> ID= 732 NAME= F <G < A <CLASSDEF <CLASSDEF 130E5665 GLYPH= AFII62821 GLYPH= AFII <CLASSDEF 86F84501 GLYPH= AFII E2C20 GLYPH= AFII64241 F ED54CE F A754 CAD3D3D0 5FEF049B ID= 969 NAME= AFII57433 /> ID= 733 NAME= P <G < 496E632E <CLASSDEF <CLASSDEF GLYPH= AFII62822 GLYPH= AFII <CLASSDEF GLYPH= AFII B132A56 GLYPH= AFII64242 DE0282DD 8829B1C FA5CD C3C ID= 970 NAME= AFII62804 /> ID= 734 NAME= T <G < <CLASSDEF <CLASSDEF 69676E20 GLYPH= AFII62823 GLYPH= AFII F6D6D <CLASSDEF 696E636F GLYPH= AFII GLYPH= GLYPH E D 72706F A ID= 971 NAME= AFII62802 /> ID= 735 NAME= Q <G < 616C2053 <CLASSDEF <CLASSDEF 6F GLYPH= AFII62824 GLYPH= AFII <CLASSDEF GLYPH= AFII C GLYPH= GLYPH1025 FCA4A59F 2C0FC0B E63 652C2061 6E B 7B54541D ID= 972 NAME= AFII62803 /> ID= 736 NAME= R <G < <CLASSDEF <CLASSDEF GLYPH= AFII62825 GLYPH= AFII E17 <CLASSDEF GLYPH= AFII D GLYPH= GLYPH D0609 2A F70D ID= 973 NAME= AFII57434 /> ID= 737 NAME= S <G < <CLASSDEF <CLASSDEF GLYPH= AFII62827 GLYPH= AFII A170D <CLASSDEF 6C GLYPH= AFII GLYPH= GLYPH E311F 301D A F2C A ID= 974 NAME= AFII62807 /> ID= 738 NAME= T <G < <CLASSDEF <CLASSDEF GLYPH= AFII62828 GLYPH= AFII A <CLASSDEF GLYPH= AFII D GLYPH= GLYPH E E E ID= 975 NAME= AFII62805 /> ID= 739 NAME= V< 0F F <CLASSDEF <CLASSDEF E GLYPH= AFII62829 GLYPH= AFII E7465 GLYPH= AFII E F726B B 130E5665 ID= 976 NAME= AFII62806 /> ID= 740 NAME= B< <CLASSDEF <CLASSDEF D656E74 GLYPH= AFII62830 GLYPH= AFII A130E56 GLYPH= AFII C E2C20 496E632E 312C302A ID= 977 NAME= AFII57441 /> ID= 741 NAME= K< 69676E2C <CLASSDEF <CLASSDEF 20496E63 6C61626C GLYPH= AFII62831 GLYPH= AFII E GLYPH= AFII A B E20 ID= 978 NAME= AFII62810 /> ID= 742 NAME= P< 040B132A A <CLASSDEF <CLASSDEF F2F7777 GLYPH= AFII62832 GLYPH= AFII E GLYPH= AFII E F6D < 6D E2E63 <CLASSDEF <CLASSDEF 69616C20 6F6D2F43 GLYPH= AFII62833 GLYPH= AFII F6674 GLYPH= AFII B National Offi ce PO Box Wellington 6144 New Zealand T F E [email protected] W
Good Practice Guidelines for Software Engineering in New Zealand
ID= 116 IACUTE /> ID= 293 UDBLACUTE /> AFII10084 /> ID= 443 NCEDILLA /> ID= 452 RCEDILLA /> ID= 117 IGRAVE /> ID= 294 UDBLACUTE /> AFII10085 /> ID= 444 ID= 453 NCEDILLA /> SCIRCUMFLEX /> ID= 118 ICIRCUMFLEX
University of Maryland Fraternity & Sorority Life Spring 2015 Academic Report
University of Maryland Fraternity & Sorority Life Academic Report Academic and Population Statistics Population: # of Students: # of New Members: Avg. Size: Avg. GPA: % of the Undergraduate Population
University of Paderborn Software Engineering Group II-25. Dr. Holger Giese. University of Paderborn Software Engineering Group. External facilities
II.2 Life Cycle and Safety Safety Life Cycle: The necessary activities involving safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when
ASCII CODES WITH GREEK CHARACTERS
ASCII CODES WITH GREEK CHARACTERS Dec Hex Char Description 0 0 NUL (Null) 1 1 SOH (Start of Header) 2 2 STX (Start of Text) 3 3 ETX (End of Text) 4 4 EOT (End of Transmission) 5 5 ENQ (Enquiry) 6 6 ACK
Controlling Risks Risk Assessment
Controlling Risks Risk Assessment Hazard/Risk Assessment Having identified the hazards, one must assess the risks by considering the severity and likelihood of bad outcomes. If the risks are not sufficiently
HTML Codes - Characters and symbols
ASCII Codes HTML Codes Conversion References Control Characters English version Versión español Click here to add this link to your favorites. HTML Codes - Characters and symbols Standard ASCII set, HTML
A Risk Management Standard
A Risk Management Standard Introduction This Risk Management Standard is the result of work by a team drawn from the major risk management organisations in the UK, including the Institute of Risk management
Table of Contents Appendix 4-9
Table of Contents Appendix 4-9 Appendix Multi-Input Thermometer & Datalogger Software Manual v1.0 4-8 Table of Contents 1. Introduction...1-1 1.1 Operation Environment...1-1 1.2 Hardware...1-1 1.3 Connecting
Regulatory Compliance Needs Process Management
White Paper Regulatory Compliance Needs Process Management A Pathfinder Technology Solutions Whitepaper October 22, 2004-1 - Introduction All businesses need to comply with government regulations, regardless
information Records Management Checklist business people security preservation accountability Foreword Introduction Purpose of the checklist
Records Management Checklist Foreword We fi rst developed the Records Management Checklist in 2008 to complement our performance audit Records Management in the Victorian Public Sector. At that time the
Vetting Smart Instruments for the Nuclear Industry
TS Lockhart, Director of Engineering Moore Industries-International, Inc. Vetting Smart Instruments for the Nuclear Industry Moore Industries-International, Inc. is a world leader in the design and manufacture
RISK MANAGEMENT FOR INFRASTRUCTURE
RISK MANAGEMENT FOR INFRASTRUCTURE CONTENTS 1.0 PURPOSE & SCOPE 2.0 DEFINITIONS 3.0 FLOWCHART 4.0 PROCEDURAL TEXT 5.0 REFERENCES 6.0 ATTACHMENTS This document is the property of Thiess Infraco and all
Windows - Alt Key Numeric Codes
Page 1 of 7 Teaching and Learning with Technology TLT Home : TLT Suggestions HOME BY LANGUAGE BASICS ACCENTS WEB DEVEL GLOSSARY SITE MAP LOCATION: Accents» Windows» Alt Key Numeric Codes Windows - Alt
Project Management Institute PRACTICE STANDARD FOR PROJECT RISK MANAGEMENT
Project Management Institute PRACTICE STANDARD FOR PROJECT RISK MANAGEMENT ISBN: 978-1-933890-38-8 Published by: Project Management Institute, Inc. 14 Campus Boulevard Newtown Square, Pennsylvania 19073-3299
Records Management Checklist. preservation. accountability. information. security. peoplep. A tool to improve records management
Records Management Checklist preservation accountability information security busine ess peoplep A tool to improve records management preservation people security business Foreword accountability information
Antykwa Toruńska. ver. 2.03. Type designer: Zygfryd Gardzielewski, Toruń, Poland. Font author: Janusz Marian Nowacki, Grudziądz, Poland.
The Polish TEXUsersGroup, GUST, supports initiatives leading to digitization of Polish traditional fonts. GUST also supports polonization of popular fonts published under GNU or GNU-like licences. The
AFTRS Health and Safety Risk Management Policy
AFTRS Health and Safety Risk Management Policy Responsible Officer Contact Officer Authorisation Director, Corporate and Student Services Head of Human Resources Chief Executive Officer Effective Date
User Guide LabelManager 420P
User Guide LabelManager 420P 17 18 19 20 21 22 16 1 15 2 14 13 3 4, - + 5 % Shift 6 12 7 8 11 10 9 Figure 1DYMO LabelManager 420P label maker 1 Print 9 Accented characters 17 Format 2 Preview 10 Space
ENTERPRISE RISK MANAGEMENT FRAMEWORK
ROCKHAMPTON REGIONAL COUNCIL ENTERPRISE RISK MANAGEMENT FRAMEWORK 2013 Adopted 25 June 2013 Reviewed: October 2015 TABLE OF CONTENTS 1. Introduction... 3 1.1 Council s Mission... 3 1.2 Council s Values...
Functional safety. Essential to overall safety
Functional safety Essential to overall safety What is Functional safety? In public spaces, factories, offi ces or homes; we are surrounded by an increasing number of electric and electronic devices and
Risk Assessment for Medical Devices. Linda Braddon, Ph.D. Bring your medical device to market faster 1
Risk Assessment for Medical Devices Linda Braddon, Ph.D. Bring your medical device to market faster 1 My Perspective Work with start up medical device companies Goal: Making great ideas into profitable
HOW PREDICTIVE ANALYTICS DRIVES PROFITABILITY IN ASSET FINANCE
HOW PREDICTIVE ANALYTICS DRIVES PROFITABILITY IN ASSET FINANCE By Janet Orrick, Analytic Scientist at International Decision Systems EXECUTIvE SUMMARY In today s ever-changing business world, asset finance
Shepway District Council Risk Management Policy
Shepway District Council Risk Management Policy Contents Section 1 Risk Management Policy... 3 1. Updates and amendments... 3 2. Definition... 3 3. Policy statement... 3 4. Objectives... 3 Section 2 Risk
Guidance note. Risk Assessment. Core concepts. N-04300-GN0165 Revision 4 December 2012
Guidance note N-04300-GN0165 Revision 4 December 2012 Risk Assessment Core concepts The operator of an offshore facility must conduct a detailed and systematic formal safety assessment, which includes
RISK MANAGEMENT GUIDANCE FOR GOVERNMENT DEPARTMENTS AND OFFICES
RISK MANAGEMENT GUIDANCE FOR GOVERNMENT DEPARTMENTS AND OFFICES GOVERNMENT ACCOUNTING SECTION DEPARTMENT OF FINANCE MARCH 2004 Risk Management Guidance CONTENTS Pages List of guidelines on risk management
THE WELL MANAGED ORGANISATION GUIDELINES FOR BOARDS
MINISTERIAL TASK FORCE ON HEALTH, SAFETY AND PRODUCTIVITY THE WELL MANAGED ORGANISATION GUIDELINES FOR BOARDS SEPTEMBER 2006 THE WELL MANAGED ORGANISATION - GUIDELINES FOR BOARDS Workplace absence and
3.4.4 Description of risk management plan Unofficial Translation Only the Thai version of the text is legally binding.
- 1 - Regulation of Department of Industrial Works Re: Criteria for hazard identification, risk assessment, and establishment of risk management plan B.E. 2543 (2000) ---------------------------- Pursuant
Operational Risk Publication Date: May 2015. 1. Operational Risk... 3
OPERATIONAL RISK Contents 1. Operational Risk... 3 1.1 Legislation... 3 1.2 Guidance... 3 1.3 Risk management process... 4 1.4 Risk register... 7 1.5 EBA Guidelines on the Security of Internet Payments...
MANAGING HAZARDS TO PREVENT MAJOR INDUSTRIAL ACCIDENTS
HEALTH AND SAFETY IN EMPLOYMENT ACT 1992 APPROVED CODE OF PRACTICE FOR MANAGING HAZARDS TO PREVENT MAJOR INDUSTRIAL ACCIDENTS OCCUPATIONAL SAFETY & HEALTH SERVICE DEPARTMENT OF LABOUR TE TARI MAHI ISSUED
Title: Basic Principles of Risk Management for Medical Device Design
Title: Basic Principles of Risk Management for Medical Device Design WHITE PAPER Author: Ganeshkumar Palanichamy Abstract Medical devices developed for human application are used for diagnostic or treatment
Information Security Policy September 2009 Newman University IT Services. Information Security Policy
Contents 1. Statement 1.1 Introduction 1.2 Objectives 1.3 Scope and Policy Structure 1.4 Risk Assessment and Management 1.5 Responsibilities for Information Security 2. Compliance 3. HR Security 3.1 Terms
ÕÙ ØÝ ÌÖ Ò Ý ÁÒ Ø ØÙØ ÓÒ Ð ÁÒÚ ØÓÖ ÌÓ ÖÓ ÓÖ ÆÓØ ØÓ ÖÓ Ì Ó Ø ÆÓÖÛ Ò È ØÖÓÐ ÙÑ ÙÒ º Ê Ò Æ ÆÓÖ Ò ÖÒØ ÖÒ Ö ÆÓÖ Ò Ò ÆÓÖÛ Ò Ë ÓÓÐ Ó Å Ò Ñ ÒØ ½ Â ÒÙ ÖÝ ¾¼¼¼ ØÖ Ø Ì Ó Ø ØÓ Ò Ø ØÙØ ÓÒ Ð ÒÚ ØÓÖ Ó ØÖ Ò ÕÙ ØÝ Ö Ó
ÌÖ Ò Ø ÓÒ¹ Ö Ò Ò ÅÒ ÑÓ ÝÒ È Ö¹ØÓ¹È Ö ËØ ÒÓ Ö Ô ËØÓÖ ËÝ Ø Ñ Ì ÑÓØ Ý ÊÓ Ó ½ Ò ËØ Ú Ò À Ò ¾ ¾ ½ ËÔÖ ÒØ Ú Ò Ì ÒÓÐÓ Ý Ä ÓÖ ØÓÖÝ ÙÖÐ Ò Ñ ¼½¼ ÍË ÍÒ Ú Ö ØÝ Ó Ñ Ö ÓÑÔÙØ Ö Ä ÓÖ ØÓÖÝ Ñ Ö ¼ Íà ØÖ غ ÅÒ ÑÓ ÝÒ Ô Ö¹ØÓ¹Ô
Information Security Policies. Version 6.1
Information Security Policies Version 6.1 Information Security Policies Contents: 1. Information Security page 3 2. Business Continuity page 5 3. Compliance page 6 4. Outsourcing and Third Party Access
Hazard Identification and Risk Assessment in Foundry
Hazard Identification and Risk Assessment in Foundry M.SaravanaKumar 1, Dr.P.SenthilKumar 2 1 (Industrial Safety Engineering, K.S.R, College of Engineering / Anna University, Chennai, India) 2 (Department
Fundamentals Level Skills Module, Paper F5
Answers Fundamentals Level Skills Module, Paper F5 Performance Management June 2010 Answers 1 (a) Costs and quoted prices for the GC and the EX using labour hours to absorb overheads: GC $ EX $ Materials
3.0 Risk Assessment and Analysis Techniques and Tools
3.0 Risk Assessment and Analysis Techniques and Tools Risks are determined in terms of the likelihood that an uncontrolled event will occur and the consequences of that event occurring. Risk = Likelihood
Old myths & recent realities
EU Collective Old myths & recent realities Redress 0( AT ) A r b e i t e r k a m m e r ( AT ) Ve r e i n f ü r K o n s u m e n t e n i n f o r m a t i o n ( B E ) Te s t - A c h a t s / Te s t - A a n
Sector Development Ageing, Disability and Home Care Department of Family and Community Services (02) 8270 2218
Copyright in the material is owned by the State of New South Wales. Apart from any use as permitted under the Copyright Act 1968 and/or as explicitly permitted below, all other rights are reserved. You
ICAEW TECHNICAL RELEASE TECH 01/11
ICAEW TECHNICAL RELEASE TECH 01/11 TECH 01/11: GUIDANCE FOR DIRECTORS ON ACCOUNTING RECORDS UNDER THE COMPANIES ACT 2006 Contents Paragraph Introduction 1-4 The legal requirements 5-9 The accounts to which
ÍÒ Ö Ø Ò Ò Ø ÒØ ÖÔÖ ÁÒ ÓÖÑ Ø ÓÒ ËÝ Ø Ñ Ì ÒÓÐÓ Ý Ó Ò ÊÈ Ö Ï Ò Ö ØØÔ»»ÛÛÛº Ò º Ù¹ ÖÐ Òº» Û Ò Ö ÁÒ Ø ØÙØ ĐÙÖ ÁÒ ÓÖÑ Ø Ö ÍÒ Ú Ö ØĐ Ø ÖÐ Ò Ì Ù ØÖº ¹½ ½ ÖÐ Ò ÖÑ ÒÝ ¹Ñ Ð Û Ò º Ù¹ ÖÐ Òº ÔÖ Ð ¾ ¾¼¼¼ ÌÙØÓÖ Ð Ø Ø
ÆÏ ÈÈÊÇÀ ÌÇ Ëµ ÁÆÎÆÌÇÊ ËËÌÅË ÂÒ¹ÉÒ ÀÙ ÅÒÙØÙÖÒ ÒÒÖÒ Ó ØÓÒ ÍÒÚÖ ØÝ ËÓÖ ÆÒÒÙÙÐ Ý Ò Ï¹Ó ÓÒ Ý ÐØÖÐ Ò ÓÑÔÙØÖ ÒÒÖÒ ÍÒÚÖ ØÝ Ó Å Ù ØØ ÑÖ Ø ÖÙÖÝ ØÖØ ÁÒ Ø ÔÔÖ Û ÓÒ Ö ÔÖÓ ÖÚÛ Ëµ ÒÚÒØÓÖÝ Ý ØÑ ÛØ ÒÔÒÒØ Ò ÒØÐÐÝ ØÖÙØ
Risk Management. A guide to help you manage events or circumstances that have a negative effect on your business
Risk Management A guide to help you manage events or circumstances that have a negative effect on your business This guide describes the risk management process, defines a risk, identifies some common
Module 4. Risk assessment for your AML/CTF program
Module 4 Risk assessment for your AML/CTF program AML/CTF Programs Risk assessment for your AML/CTF program Page 1 of 27 Module 4 Risk assessment for your AML/CTF program Risk assessment for your AML/CTF
PROCESSOR IS OCCUPIED BY T i
ËÙÐÒ ÐÓÖØÑ ÓÖ ÅÙÐØÔÖÓÖÑÑÒ Ò ÀÖ¹ÊйÌÑ ÒÚÖÓÒÑÒØ º ĺ ÄÙ ÈÖÓØ Å Å Ù ØØ ÁÒ ØØÙØ Ó ÌÒÓÐÓÝ ÂÑ Ïº ÄÝÐÒ ÂØ ÈÖÓÔÙÐ ÓÒ ÄÓÖØÓÖÝ ÐÓÖÒ ÁÒ ØØÙØ Ó ÌÒÓÐÓÝ ØÖØ Ì ÔÖÓÐÑ Ó ÑÙÐØÔÖÓÖÑ ÙÐÒ ÓÒ ÒÐ ÔÖÓ ÓÖ ØÙ ÖÓÑ Ø ÚÛÔÓÒØ Ó Ø ÖØÖ
ASCII control characters (character code 0-31)
ASCII control characters (character code 0-31) DEC HEX 0 00 NUL Null char 1 01 SOH Start of Heading 2 02 STX Start of Text 3 03 ETX End of Text 4 04 EOT End of Transmission
Functional Safety Management: As Easy As (SIL) 1, 2, 3
Functional Safety Management: As Easy As (SIL) 1, 2, 3 Abstract This paper outlines the need for planning in functional safety management. Recent events such as the Montara blowout and the Deepwater Horizon
Ò Ñ Ö Ð ÓÙÒ Ø ÓÒ ÓÖ ÙØÓÑ Ø Ï ÁÒØ Ö Ú ÐÙ Ø ÓÒ Ý Å ÐÓ Ý Ú ØØ ÁÚÓÖÝ ºËº ÈÙÖ Ù ÍÒ Ú Ö ØÝµ ½ ź˺ ÍÒ Ú Ö ØÝ Ó Ð ÓÖÒ Ø Ö Ð Ýµ ½ ÖØ Ø ÓÒ Ù Ñ ØØ Ò ÖØ Ð Ø Ø ÓÒ Ó Ø Ö ÕÙ Ö Ñ ÒØ ÓÖ Ø Ö Ó ÓØÓÖ Ó È ÐÓ Ó Ý Ò ÓÑÙØ Ö
Slums and informal settlements An evidence-based approach to sustainable upgrading and development
Slums and informal settlements An evidence-based approach to sustainable upgrading and development 1 billion people currently live in slums, this is set to double over the next 30 years. Slums are a physical
ÔØÖ ÄÒÖ Ç ÐÐØÓÖ ß ÇÒ Ö Ó ÖÓÑ º½ ÇÚÖÚÛ ÏØ Ó Ø ØÒ Ú Ò ÓÑÑÓÒ ÔÖÓÔØÓÒ Ó Ñ ÛÚ ÒÖØ Ý ÖØ¹ ÕÙ ÖÑÓØ ØØÓÒ Ó ÓÑÔÐÜ ÑÓÐÙÐ Ú ÒÖÖ ÔØÖ Ø ÐØÖ Ò ÑÒØ Ð Ò ÑÖÓÛÚ ÚØÝ Ò ÖÒØÖ ÐÓ Ì ÙÑÐ ÑÔÐ ÖÑÓÒ Ó Ð¹ ÐØÓÖ ÔÐÝ ØÖÖÒ ÖÓÐ Ò Ø ÙÒÖ
Risk Management Policy
Risk Management Policy DOCUMENT CONTROL Developed by: Date: Origination: Quality, Systems & Shared s March 2014 Authorised by: Colette Kelleher April 2014 DOCUMENT REVIEW HISTORY Original Circulation date:
Risk Management Policy and Framework
Risk Management Policy and Framework December 2014 phone 1300 360 605 08 89589500 email [email protected] location 1Bagot Street Alice Springs NT 0870 post PO Box 2257 Alice Springs NT 0871
(a) Hidden Terminal Problem. (b) Direct Interference. (c) Self Interference
ØÖ ÙØ ÝÒ Ñ ÒÒ Ð Ë ÙÐ Ò ÓÖ ÀÓ Æ ØÛÓÖ ½ Ä ÙÒ Ó Ò ÂºÂº Ö ¹ÄÙÒ ¹ Ú Ë ÓÓÐ Ó Ò Ò Ö Ò ÍÒ Ú Ö ØÝ Ó Ð ÓÖÒ Ë ÒØ ÖÙÞ ¼ ¹Ñ Ð ÓÐ Ó ºÙ º Ù Î Ö ÓÒ ¼»½»¾¼¼¾ Ì Ö ØÝÔ Ó ÓÐÐ ÓÒ¹ Ö ÒÒ Ð ÔÖÓØÓÓÐ ÓÖ Ó Ò ØÛÓÖ Ö ÔÖ ÒØ º Ì ÔÖÓØÓÓÐ
ÔØ Ö Ê Ö ÓÐÓ Ý ÁÒ Ø ÔØ Ö Ø Ö Ñ Ò ÛÓÖ Ø Ø ÓÒ Ú ÐÓÔ ÔÖ ÒØ º Ì ÛÓÖ Ø ¹ Ø ÓÒ ÓÑÔÙØ Ö Ø ÒÓ Ø ÑÓ ÙÐ Û Ö Ø ÓÖÓÒ ÖÝ ØÖ ÑÓ Ð ÐÐ ÔÐ Ý Ò ÑÔÓÖØ ÒØ ÖÓÐ Û Ò Ó Ò ÙØÓÑ Ø Ú Ð Ò ÐÝ Û Ø ÓÖÓÒ ÖÝ Ò Ó Ö ¹ Ô Ý Ñ º Ì ÔØ Ö Ò Û
ÆÓØ Ä ØÙÖ Ð Ñ Ø ØÖÙ ÙØ ÓÒ ØÓ Á ¼ ØÙ ÒØ ÓÖ ÐÐ ÓØ Ö Ö Ø Ö ÖÚ Á ¼ ÈÊÇ Í ÌÁÇÆ ÈÄ ÆÆÁÆ Æ ÇÆÌÊÇÄ Ê Æ Ô ÖØÑ ÒØ Ó ÁÒ Ù ØÖ Ð Ò Ò Ö Ò ÍÒ Ú Ö ØÝ Ø Ù«ÐÓ ¹ ËØ Ø ÍÒ Ú Ö ØÝ Ó Æ Û ÓÖ Ò Ù«ÐÓº Ù Á ¼ ÈÊÇ Í ÌÁÇÆ ÈÄ ÆÆÁÆ Æ
Ê ½µ ¼»¼»¼½ ÓÑÔÙØÖ ËÒ»ÅØÑØ ½ Ô Ê Ö ÊÔÓÖØ Ì ÈÊËÍË ËÝ ØÑ ÖØØÙÖ ÖØ ÈØÞÑÒÒ ½ ÂÑ ÊÓÖÒ ¾ Ö ØÒ ËØÐ ½ ÅÐ ÏÒÖ ¾ ÖÒ ÏÖ ½ ÍÒÚÖ ØØ ËÖÐÒ ÁÑ ËØØÛÐ ¹½¾ ËÖÖÒ ÖÑÒÝ ßÔØÞÑÒÒ ØÙÐÐ ºÙÒ¹ º ¾ ÁÅ ÙÖ Ê Ö ÄÓÖØÓÖÝ ËÙÑÖ ØÖ À¹¼ Ê
CONTROL AND COMPLIANCE AUDITS
V I C T O R I A Auditor-General of Victoria CONTROL AND COMPLIANCE AUDITS Payroll management and Administration of the goods and services tax March 2003 Ordered to be printed by Authority. Government Printer
Constraining the cumulative amount of revenue recognised
IASB Agenda ref 7A STAFF PAPER Week of 24 September 2012 FASB IASB Meeting Project Revenue Recognition FASB Education Session 19 September, 2012 IASB Education Session 20 September, 2012 Paper topic Constraining
ÓÑÔ Ö Ø Ú ËØÙ Ý Ó ÌÛÓ ØÖÓÒÓÑ Ð ËÓ ØÛ Ö È Ò Ì Ø Ù Ñ ØØ Ò Ô ÖØ Ð ÙÐ ÐÐÑ ÒØ Ó Ø Ö ÕÙ Ö Ñ ÒØ ÓÖ Ø Ö Ó Å Ø Ö Ó Ë Ò Ò ÓÑÔÙØ Ö Ë Ò Ì ÍÒ Ú Ö ØÝ Ó Ù Ð Ò ½ ÌÓ ÅÙÑ Ò Ò ØÖ Ø Ì Ø ÓÑÔ Ö Ø Ú ØÙ Ý Ó ØÛÓ ÓÔ Ò ÓÙÖ ØÖÓÒÓÑ
Analyzing the Security Significance of System Requirements
Analyzing the Security Significance of System Requirements Donald G. Firesmith Software Engineering Institute [email protected] Abstract Safety and security are highly related concepts [1] [2] [3]. Both
IEC 61508 Overview Report
IEC 61508 Overview Report A Summary of the IEC 61508 Standard for Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems exida Sellersville, PA 18960, USA +1-215-453-1720
With the introduction of GAMP 5, A
Online Exclusive from PHARMACEUTICAL ENGINEERING The Official Magazine of ISPE January/February 2012, Vol. 32 No. 1 www.pharmaceuticalengineering.org Copyright ISPE 2012 This article presents the case
ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL
61508-3 ª IEC: 1997 1 Version 12.0 05/12/97 COMMISSION CEI ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL COMMISSION Functional safety of electrical/electronic/ programmable
Version: 3.0. Effective From: 19/06/2014
Policy No: RM66 Version: 3.0 Name of Policy: Business Continuity Planning Policy Effective From: 19/06/2014 Date Ratified 05/06/2014 Ratified Business Service Development Committee Review Date 01/06/2016
Walk around and identify the area to be assessed and look at what could reasonably be expected to cause harm.
Risk Assessment Introduction The assessment of risk is central to the management of health and safety. The purpose of this is to assist in identifying those measures which are needed to remove or otherwise
ÓÒØÖÓÐ ËÝ Ø Ñ Ò Ò Ö Ò ÖÓÙÔ Ò ÙØÓÑ Ø ÓÒ Ì ÒÓÐÓ Ý ÖÓÙÔ Ö¹ÁÒ Ò Ö ÂÓ Ñ ÔÙØÝµ Ø ØÖ ½ ¼ ¼ À Ò È ÓÒ ¼¾ ½¹ ¹½½¼¼ Ü ¼¾ ½¹ ¹ ¹Å Ð Ò Ö Ó Ñ ÖÒÙÒ ¹ Ò Ñ Ø «È ÓÒ ÓÒØÖÓÐ ËÝ Ø Ñ Ò Ò Ö Ò ÖÓÙÔ ÔйÁÒ Ò Ö Ó«Ö¹ÁÒ ÍÐÖ ÓÖ ÓÐØ
QUALITY RISK MANAGEMENT (QRM): A REVIEW
Lotlikar et al Journal of Drug Delivery & Therapeutics; 2013, 3(2), 149-154 149 Available online at http://jddtonline.info REVIEW ARTICLE QUALITY RISK MANAGEMENT (QRM): A REVIEW Lotlikar MV Head Corporate
GUIDANCE MATERIAL GUIDANCE ON THE USE OF POSITIVE PERFORMANCE INDICATORS TO IMPROVE WORKPLACE HEALTH AND SAFETY
GUIDANCE MATERIAL GUIDANCE ON THE USE OF POSITIVE PERFORMANCE INDICATORS TO IMPROVE WORKPLACE HEALTH AND SAFETY Office of the Australian Safety and Compensation Council NOVEMBER 2005 IMPORTANT NOTICE The
Bud row 1. Chips row 2. Coors. Bud. row 3 Milk. Chips. Cheesies. Coors row 4 Cheesies. Diapers. Milk. Diapers
Ð ØÖ ØÝ ÜØ ÖÒ Ð Ë Ñ Ð Ö ØÝ Ó Ø ÓÖ Ð ØØÖ ÙØ Ö ØÓÔ Ö Êº È ÐÑ Ö ½ Ò Ö ØÓ ÐÓÙØ Ó ¾ ¾ ½ Î Ú ÑÓ ÁÒº ¾ ÛÓÓ ÐÚ È ØØ ÙÖ È Ô ÐÑ ÖÚ Ú ÑÓºÓÑ ÓÑÔÙØ Ö Ë Ò Ô ÖØÑ ÒØ ÖÒ Å ÐÐÓÒ ÍÒ Ú Ö ØÝ ¼¼¼ ÓÖ Ú È ØØ ÙÖ È Ö ØÓ ºÑÙº Ù
Applications. Decode/ Encode ... Meta- Data. Data. Shares. Multi-read/ Multi-write. Intermediary Software ... Storage Nodes
ËÐØÒ Ø ÊØ Ø ØÖÙØÓÒ ËÑ ÓÖ ËÙÖÚÚÐ ËØÓÖ ËÝ ØÑ ÂÝ Âº ÏÝÐ ÅÑØ ÐÓÐÙ ÎÝ ÈÒÙÖÒÒ ÅРϺ Ö ËÑ ÇÙÞ ÃÒ ÌÛ ÓÖÝ ÏÐÐÑ ÖÓÖÝ Êº ÒÖ ÈÖÔ Ãº ÃÓ Ð ÅÝ ¾¼¼½ Å͹˹¼½¹½¾¼ ËÓÓÐ Ó ÓÑÔÙØÖ ËÒ ÖÒ ÅÐÐÓÒ ÍÒÚÖ ØÝ ÈØØ ÙÖ È ½¾½ ØÖØ ËÙÖÚÚÐ
ÓÒØÜØ¹ ÔÔÖÓ ÓÖ ÅÓÐ ÔÔÐØÓÒ ÚÐÓÔÑÒØ ÄÙØÓ ÆÙÖÓÓ ÁÖº ŵ ź˺ ÂÑ ÓÓµ Ì ÙÑØØ Ò ÙÐ ÐÐÑÒØ Ó Ø ÖÕÙÖÑÒØ ÓÖ Ø Ö Ó ÓØÓÖ Ó ÈÐÓ ÓÔÝ ËÓÓÐ Ó ÓÑÔÙØÖ ËÒ Ò ËÓØÛÖ ÒÒÖÒ ÅÓÒ ÍÒÚÖ ØÝ ÅÖ ¾¼¼½ ÐÖØÓÒ Ì Ø ÓÒØÒ ÒÓ ÑØÖÐ ØØ Ò ÔØ ÓÖ
Dealer and Broker Guide. to Financial Conduct Authority Regulation. Dealer_conduct_guide_Oct15 This is a Business-to-Business communication
Dealer and Broker Guide to Financial Conduct Authority Regulation Dealer_conduct_guide_Oct15 This is a Business-to-Business communication Legal Disclaimer The information contained in this Dealer and Broker
Ê ÔÓÒ Ú Ì ÒÛ Ö Î Ù Ð Þ Ø ÓÒ Ó Ä Ö Ó Ö Ô Ø Ø Ý Ã ÒÒ Ø Ò ÖØ Ø ÓÒ Ù Ñ ØØ Ò Ô ÖØ Ð ÙÐ ÐÐÑ ÒØ Ó Ø Ö ÕÙ Ö Ñ ÒØ ÓÖ Ø Ö Ó ÓØÓÖ Ó È ÐÓ ÓÔ Ý Ô ÖØÑ ÒØ Ó ÓÑÔÙØ Ö Ë Ò Æ Û ÓÖ ÍÒ Ú Ö ØÝ Ë ÔØ Ñ Ö ¾¼¼¾ ÔÔÖÓÚ Ô Ã ÒÒ Ø Ò
FRAME. ... Data Slot S. Data Slot 1 Data Slot 2 C T S R T S. No. of Simultaneous Users. User 1 User 2 User 3. User U. No.
ÂÓÙÖÒ ÐÓ ÁÒØ ÖÓÒÒ Ø ÓÒÆ ØÛÓÖ ÎÓк¾ ÆÓº½ ¾¼¼½µ ¹ ÏÓÖÐ Ë ÒØ ÈÙ Ð Ò ÓÑÔ ÒÝ È Ê ÇÊÅ Æ Î ÄÍ ÌÁÇÆÇ Ê ÉÍ ËÌ¹Ì Å» Å ÈÊÇÌÇ ÇÄ ÇÊÏÁÊ Ä ËËÆ ÌÏÇÊÃË ÒØ Ö ÓÖÊ Ö ÒÏ Ö Ð ÅÓ Ð ØÝ Ò Æ ØÛÓÖ Ò Ê ÏŠƵ Ô ÖØÑ ÒØÓ ÓÑÔÙØ ÖË Ò
Third party use of customer lists
May 2006 slaughter and may marketing: part 4 Third party use of customer lists Rob Sumroy, Partner In the fi rst article in this series we considered the legislative and regulatory framework that direct
Æ ÒØ Ò Ö Ø ÓÒ Ó ÊÓØ Ø Ò ÏÓÖ ÓÖ Ë ÙÐ ÆÝ Ö Ø ÅÙ Ð ÂÓ ÒÒ Đ ÖØÒ Ö Ò ÏÓÐ Ò ËÐ ÒÝ ØÖ غ Ò Ö Ø Ò ¹ÕÙ Ð ØÝ ÙÐ ÓÖ ÖÓØ Ø Ò ÛÓÖ ÓÖ Ö Ø Ð Ø Ò ÐÐ ØÙ Ø ÓÒ Û Ö ÖØ Ò Ø ÆÒ Ð Ú Ð ÑÙ Ø Ù Ö¹ ÒØ Ù Ò Ò Ù ØÖ Ð ÔÐ ÒØ Ó Ô Ø Ð
Commonwealth Risk Management Policy
Commonwealth Risk Management Policy 1 July 2014 Department of Finance Business, Procurement and Asset Management 978-1-922096-51-7 (Print) 978-1-922096-50-0 (Online) Copyright Notice Content This work
Title: OHS Risk Management Procedure
Issue Date: July 2011 Review Date: July 2013 Page Number: 1 of 9 1. Purpose: To outline the methodology by which Department of Education and Early Childhood Development (DEECD) identifies, assesses, controls
Software-based medical devices from defibrillators
C O V E R F E A T U R E Coping with Defective Software in Medical Devices Steven R. Rakitin Software Quality Consulting Inc. Embedding defective software in medical devices increases safety risks. Given
Risk management a practical approach
Risk management a practical approach Introduction Preventing work related accidents and injuries is the primary concern for all those involved in health and safety. Work related accidents and injuries
Regulations on Information Systems Security. I. General Provisions
Riga, 7 July 2015 Regulations No 112 (Meeting of the Board of the Financial and Capital Market Commission Min. No 25; paragraph 2) Regulations on Information Systems Security Issued in accordance with
River Stour (Kent) Internal Drainage Board Risk Management Strategy and Policy
River Stour (Kent) Internal Drainage Board Risk Management Strategy and Policy Page: 1 Contents 1. Purpose, Aims & Objectives 2. Accountabilities, Roles & Reporting Lines 3. Skills & Expertise 4. Embedding
Crime Statistics Data Security Standards. Office of the Commissioner for Privacy and Data Protection
Crime Statistics Data Security Standards Office of the Commissioner for Privacy and Data Protection 2015 Document details Security Classification Dissemination Limiting Marker Dissemination Instructions
identify hazards, analyze or evaluate the risk associated with that hazard, and determine appropriate ways to eliminate or control the hazard.
What is a risk assessment? Risk assessment is the process where you: identify hazards, analyze or evaluate the risk associated with that hazard, and determine appropriate ways to eliminate or control the
Risk Assessment. Module 1. Health & Safety. Essentials. 16-23 November 2013. Registered charity number 207890
Risk Assessment Module 1 Risk assessment in the laboratory After studying this module you will be able to understand the need to conduct risk assessments, how this applies to all laboratory activities,
Universitat Autònoma de Barcelona
Universitat Autònoma de Barcelona ÙÐØ Ø Ò Ë Ó ³ Ò ÒÝ Ö ÁÒ ÓÖÑ Ø ÇÒ Ø Ò Ò ÓÒ ØÖÙØ ÓÒ Ó ÒØ¹Ñ Ø ÁÒ Ø ØÙØ ÓÒ Å Ñ ÓÖ ÔÖ ÒØ Ô Ö Ò ÂÙ Ò ÒØÓÒ Ó ÊÓ Ö Ù Þ Ù Ð Ö Ô Ö ÓÔØ Ö Ð Ö Ù ÓØÓÖ Ò ÒÝ Ö Ò ÁÒ ÓÖÑ Ø ÐÐ Ø ÖÖ Å ¾¼¼½
Specialists in Strategic, Enterprise and Project Risk Management. PROJECT RISK MANAGEMENT METHODS Dr Stephen Grey, Associate Director
BROADLEAF CAPITAL INTERNATIONAL PTY LTD ACN 054 021 117 23 Bettowynd Road Tel: +61 2 9488 8477 Pymble Mobile: +61 419 433 184 NSW 2073 Fax: + 61 2 9488 9685 Australia www.broadleaf.com.au [email protected]
Ë ÓÒ Ð ØÝ Ò Ö ÙÐØÙÖ Ð ÓÑÑÓ ØÝ ÙØÙÖ Ö Ø Ò Ë Ö Ò Ò Ô ÖØÑ ÒØ Ó Ò Ò ÓÔ Ò Ò Ù Ò Ë ÓÓÐ ÊÓ Ò ÖÒ ÐÐ ½ ù½ ¼ Ö Ö Ö ÒÑ Ö Ì Ä ½ ½ ½ ¼¼ ¹Ñ Ð Óº º Ñ Ö ½ Ì ÙØ ÓÖ Ø Ò ÓÖ ÐÔ ÙÐ Ø Ò ÖÓÑ Â Ô Ö ĐÙÐÓÛ Ò ÓÑÑ ÒØ Ò Ù Ø ÓÒ ÖÓÑ
General Terms and Conditions for the Purchase and Maintenance of Hardware
General Terms and Conditions for the Purchase and Maintenance of Hardware A COMMON INTRODUCTORY PROVISIONS 1 Object and validity 1.1 The present General Terms and Conditions (GTC) govern the conclusion,
Auditing IT Service Management
INTOSAI 2001 Auditing IT Service Management RISK ASSESSMENT Preface The IT Infrastructure Management Project was initiated by INTOSAI Standing Committee on IT Audit at its 8 th meeting in October 1999.
Hazard Identification, Risk Assessment and Control Procedure
Hazard Identification, Risk Assessment and Control Procedure 1. Purpose To ensure that there is a formal process for hazard identification, risk assessment and control to effectively manage workplace and
PROCEDURES RISK MANAGEMENT FRAMEWORK AND GUIDELINES PURPOSE INTRODUCTION. 1 What is Risk?
PROCEDURES RISK MANAGEMENT FRAMEWORK AND GUIDELINES PURPOSE This Framework and Guidelines have been developed in support of the CQUniversity Risk Management Policy and are intended for use by the CQUniversity
Capital Adequacy: Advanced Measurement Approaches to Operational Risk
Prudential Standard APS 115 Capital Adequacy: Advanced Measurement Approaches to Operational Risk Objective and key requirements of this Prudential Standard This Prudential Standard sets out the requirements
