Safety-Critical Certification Options for Your Next Device

Transcription

1 Safety-Critical Certificatin Optins fr Yur Next Device Tdd Brian Directr f Sales and Marketing, Validated Sftware Crpratin September 16, 2010 ABSTRACT: The week f September 19, 2010, during the Embedded Systems Cnference s annual Bstn shw, Micriµm annunced its strategic alliance with Validated Sftware Crpratin (VSC). In the press release, the reasn fr the alliance is The gal f the alliance is t advance their prducts as the lw-risk, cst-effective alternative t ther cmmercial and in-huse systems. With strategic and tactical alignment n designs, technlgies, and accunts, the partnership will greatly increase custmer access t prven, cst effective safety-critical cmpliant RTOS technlgy. The purpse f this paper is t present: A brief verview f safety-critical sftware standards; Market trends; VSC s current supprt fr Micriµm real-time prducts. AUDIENCE: Medical, Industrial, Transprtatin, and Avinics device develpers and managers wh are cnsidering the use f a cmmercial embedded RTOS as the fundatin fr their develpment Embarcader Lane Carlsbad, Califrnia (760)

2 Table f Cntents Safety-Critical Certificatin - Optins fr Yur Next Device... 3 Safety-critical Sftware Standards... 3 What are Safety-critical Sftware Standards?... 3 Dmain Specific... 4 Nn-Dmain Specific... 5 Criticality... 5 Safety-critical Sftware Csts... 6 Trends... 7 Develpers have Optins... 8 Meet Validated Sftware and Micriµm... 8 Micriµm... Errr! Bkmark nt defined. Validated Sftware... 9 µc/os Sftware and Certificatin Ready Evidence Trailridge Drive East Suite 102 Lafayette, Clrad (303)

3 Safety-Critical Certificatin - Optins fr Yur Next Device Safety-critical Sftware Standards With the grwing use f embedded cmputers in everyday items cmes the increasing prbability that the sftware ne develps will ultimately intersect with a safety case. Therefre, many develpers wh have nt been expsed t sftware safety standards have t develp t them nw. Hwever, there are a number f ways that develpers can reduce bth the risk and expense f writing safe sftware. One way is t eliminate all nn-cre develpment activity, such as RTOS develpment, and give it t the experts. This reduces the ttal burden, and ensures that experts are managing that part f yur sftware prgram. While the line item expense fr licensing an RTOS may stand ut, a review f what ges int the develpment, maintenance, and supprt prvided by a respnsible sftware vendr shws that utilizing their services is clearly cst effective. The same can be said fr the vendr wh validates an RTOS t varius safety standards. While safety-critical sftware develpment will never be cnsidered cheap, it can be cmpetitive and cst effective. There are a number f definitins fr safety-critical. Accrding t Wikipedia, A safety-critical system, subsystem, cnditin, event, peratin, prcess r item is ne whse prper recgnitin, cntrl, perfrmance r tlerance is essential t system peratin such that it des nt jepardize public safety." A simpler definitin f a safety-critical system is any system whse failure: Causes r allws harm r death t humans and their pets; Causes r allws envirnmental damage; Causes r allws the lst f large capital equipment. What are Safety-critical Sftware Standards? Sftware develpment standards are practices and methdlgies that cnsistently prduce rbust, reliable sftware. Safety-critical sftware develpment standards are used t develp rbust reliable sftware fr systems whse failure will lead t unacceptably adverse ends. While nt cmplete, the list belw includes a majrity f the dminant internatinally recgnized standards. RTCA DO-178C, DO-278A, EUROCAE ED-12C, ED-109A Avinics (Airbrne) IEC Industrial cntrl, autmatin, manufacturing, safety systems UL-1998 Hme, cnsumer, industrial safety IEC Medical, clinical and hme diagnstic and therapy FDA/CDRH 510(k) Medical clinical and hme diagnstic and therapy CENELEC EN Rail/transprtatin, lcmtive, signaling, and cntrl Cpyright 2010, Validated Sftware Crpratin Page 3 f 11

4 At a high level, mst safety-critical standards have tw areas f applicatin. The first area invlves detailed knwledge f the prblem dmain itself i.e., its technlgy, techniques, thery f peratin, etc. An example wuld be the research, techniques, and thery that cmprise a new heart/lung machine. The secnd area invlves detailed knwledge f the implementatin side f the device, i.e. the system and sftware dmain. The secnd part f the standard usually prvides guidance fr the implementers, thse wh create the physical system frm a set f requirements. It is this secnd area that mst sftware develpers wuld recgnize. Mst safety-critical standards prvide a great deal f guidance fr thse wh implement the actual system. Frm a sftware develpment perspective there are three cmpnents prvided by the standard directly r as a by-prduct f the guidance given t the dmain experts: Requirements as derived frm the experts in the device dmain; The level f criticality f the sftware as established by analysis within the guidance f the standard; The sftware lifecycle as defined by the standard. Dmain Specific The dmain r device specific prtin f the safety standard generally prvides guidance n: Identificatin f hazards Definitin f hazards Scpe f hazards Prbability f a hazard manifesting Human factr analysis Scpe f failure Prbabilities f failure Cnsequences f failure Severity f failure Techniques t reduce and remediatin f failures Risk analysis and abatement Assessment f risk Tlerance fr risk Methds, practices, prcedures, planning, etc. that pertain t the develpment f safety systems. It is the dmain experts that prvide the knwledge i.e., the requirements, hazard analysis, etc. that the implementers utilize t design the physical system. The abve is nt meant t be an exhaustive list, nr is it specific t a particular market, standard, r area f applicatin (dmain). It is prvided t clarify the ratinale fr the use f s many different standards. Cpyright 2010, Validated Sftware Crpratin Page 4 f 11

5 Nn-Dmain Specific The secnd part f the standard is tied t what mst sftware develpers wuld recgnize as the sftware develpment lifecycle. As stated earlier, the tw mst critical derivatives f the dmain specific prtin f the safety-critical standard are the requirements and the level f criticality f the sftware i.e., what is being built and the degree f rigr necessary t insure that it is built crrectly. It is here that the teams respnsible fr the hardware and sftware design begin their develpment prcess. Additinally, it is at this stage that a great number f similarities between safety-critical sftware standards becme nticeable. A brief lk at a crss sectin f the safety-critical sftware standards used in Avinics, Transprtatin, Medical and Industrial applicatins shws a great deal f verlap between them. In fact, as ne persn recently pinted ut during a webinar n the tpic f safety-critical sftware develpment, at a high level there is very little that differentiates gd sftware engineering practices and safety-critical sftware develpment practices. It is nt surprising. As in life, many paths lead t a single destinatin, but nly a few are "ptimal" nes. Regardless f the specific methds, paradigms, prcesses and prcedures, mst develpers agree n the five majr cmpnents that make up the sftware life cycle. 1. Requirements Analysis and Definitin 2. Sftware Design 3. Implementatin and Unit Testing 4. Integratin and System Testing 5. Operatin and Maintenance All safety-critical develpment standards additinally include a "Planning" step. It is Step 0 f safety-critical develpment. When ne talks abut the sftware life cycle, the wrd "Plan" is taken t be bth a nun and a verb. In rder t create reliable sftware ne must plan, as well as have a plan. Plan (nun): a specific prject r definite purpse, a scheme r methd f acting, ding, and prceeding. Plan (verb): t make plans, t arrange a methd r scheme befrehand fr any wrk. T plan ahead. An additinal item that separates traditinal sftware develpment frm Safety-critical Sftware Develpment practices is Prcess. Fr thse wh are nt familiar with safety-critical develpment practices, Prcess is the bedrck f Safety-Critical Sftware. Withut prcess, interjecting cnsistency (f a prven methd) t the essential cmpnents and activities f safetycritical develpment there is n assurance that success r, in this case safety, culd be maintained. Yes, prcess is cnsidered a necessary cmpnent in cmmercial sftware develpment; it is the degree f prcess that differentiates safety-critical frm cmmercial develpment practices. Criticality Mst if nt all standards prvide fr varying degrees f "Criticality" (a relative measure f severity r risk) that imply different levels f rigr that have t be applied t the develpment prcess and sftware in rder t cmply with the standard. A cmmn, yet nt entirely crrect, view f criticality is that is it a measure f the harm that might result frm a sftware failure. In reality, the definitin f criticality differs cnsiderably between standards. Cpyright 2010, Validated Sftware Crpratin Page 5 f 11

6 One measure f criticality, termed the "Safety Integrity Level" (SIL) is used by several standards. Fr Eurpean-based IEC standards, a simplistic definitin f the SIL f a safety functin is the measure f its risk reductin. A SIL f 1 is the lwest amunt f risk reductin and a SIL f 4 is the highest. Standards utside f the IEC use the SIL acrnym but it may have a slightly different meaning. In Avinics, the criticality is expressed as "level" with "Level A, being the mst stringent i.e. a failure cnsidered having catastrphic ptential. A failure f a "Level E" system has zer impact n the peratin f the aircraft. The criticality f a system is gverned by the dmain specific prtin f a safety standard; it may r may nt have dependencies n hardware aspects f the system. Fr the standard IEC-61508, the SIL f a device is derived frm bth the risk reductin gained by hardware and the sftware system as a whle. Other standards view the criticality f hardware and sftware separately. A sftware develper nly needs t knw tw things in rder t develp sftware that cmplies with a standard. They have t understand the standard and its criticality. With this knwledge in hand, a sftware develper simply adheres t the develpment practices, prcedures, methdlgies, etc. dictated by the standard and the device criticality. While verly simplified, this is the same cncept that enables cmmercial sftware and certificatin cmpanies such as Micriµm and Validated Sftware Crpratin (VSC) t prvide ff the shelf sftware and validatin prducts that serve a great number f safety-critical industries. T accmplish this Micriµm and VSC take advantage f sme aspects f each standard s criticality rankings and apply flexibility in utilizing different techniques t cmply with the requirements f a standard. While it is beynd the scpe f this paper t detail the internal requirements f the safety-critical standards, a brief clarificatin is in rder. Rather than develp a versin f sftware and its supprting evidence f cmpliance fr each criticality level f each standard, bth Micriµm s sftware and VSC s certificatin prducts explit the fact that all standards allw ne t surpass its requirements. In ther wrds, they develp their prducts s that they cmply with the highest levels that can be achieved and use that t satisfy lwer criticality requirements. This is allwed WITHIN the different levels f criticality f a standard. The secnd area f flexibility that VSC and Micriµm explit is flexibility BETWEEN the different standards --they utilize the best f class safety techniques ffered by individual standards. This serves tw purpses. As mentined earlier, it brings a higher verall safety case t bear n mst f the requirements f any particular standard, and it allws a great deal f reuse f cmpliance evidence between the varius standards. Fr a custmer, that means that even if they are develping a lw-level criticality i.e., SIL 1, r Level E, they knw that the cre RTOS sftware they received frm Micriµm can be certified t the highest levels f criticality. Furthermre, their certificatin package utilizes the best f the best techniques ffered by the crss sectin f standards that VSC supprts. While nt entirely germane t ur tpic, it is the ability t develp nce and retest n a perhardware target basis that allws VSC t prvide such cst effective pricing n its certificatin prducts. As will be cvered later, the cre validatin cmpnents fr each standard represent a huge investment f time and labr. Hwever, due t µc/os small and efficient ftprint, prting and testing t individual hardware targets is labr intensive but nt nearly t the degree impsed by ther real-time perating systems. Safety-critical Sftware Csts As shuld be bvius frm the previus discussin, Safety-critical Sftware Develpment is an expensive prpsitin. T put it in perspective, the industry average fr cmmercial embedded sftware is typically between $15 and $30 per line f cde (LOC). It may sund expensive but Cpyright 2010, Validated Sftware Crpratin Page 6 f 11

7 this is nt nly the expense f cding the sftware; this figure includes architecture and design, implementatin, testing and release. As a rule f thumb, safety-critical sftware is 5 t 10 times as expensive t develp. It ranges frm $75 t $150 per SLOC. A high-level descriptin f the Safety-critical Develpment prcess invlves: Prcess, methdlgy & dcumentatin Planning Develpment Requirements Verificatin Cnfiguratin management Quality assurance Cde Test Surce cde Test cde Test scripts Build & bject cde Cde cverage and analysis Unit/white-bx integratin/black-bx Structural Analysis Plan fr tl usage Results Accmplishment summary Unit & integratin test Requirements traceability Trace matrix T put this in perspective, the space shuttle s sftware, arguably the wrld s best, cst rughly $1,200 per each f its 420,000 SLOC. Trends Safety-critical sftware has becme a very imprtant tpic t an ever-grwing grup f develpers, manufacturers, and users. Why? It is n secret that digital cntrl is playing a greater rle in almst every human activity. In manufacturing, fr example, cmputer driven devices are mre accurate, faster, less mistake prne, and essentially tireless in their effrts. One ften hears that the cst f cmputers and digital electrnics in autmbiles is nearing 50% f the ttal manufacturing cst f an autmbile. Perhaps these statistics put it in perspective with the Cpyright 2010, Validated Sftware Crpratin Page 7 f 11

8 fllwing metrics: a typical GM car in 1970 had apprximately 100,000 SLOC, in 1990, it had apprximately 1,000,000 SLOC, and in 2010, it has apprximately 100,000,000 SLOC. While much f the sftware cntributing t this expnential grwth is nt safety r missin critical, a significant and grwing percentage is. Device cmplexity is grwing and much f it is due t cnvergence. It is clear that single-functin safety-critical devices are ging the way f the dd bird. Example: defibrillatrs used t be standalne devices, i.e., all they did was mnitr the heart rhythm and deliver a metered, therapeutic dse f electrical energy t the heart. Hwever, like many digital devices, tday's defibrillatrs als prvide wireless cnnectivity, file systems, USB, and ther infrastructure sftware. Anther example, ne that is nt new but is really starting t accelerate, is demand fr cnsumer electrnics-like user experiences in the clinical setting. One physician recent cnfided that his car stere had a mre intuitive and "fun t use" user interfaces than his $200,000 diagnstic device. Fr ther devices, the additin f things like wireless cnnectivity is essential. It has the ability t bring experts t the scene f an event and share infrmatin fr, excuse the term, "pst mrtem" analysis. Develpers are being asked t add new features t their prducts, but the funding fr travel, training r additinal staff has been reduced r eliminated. As a result, develpment effrts are starting t slip. The statistics d nt lie. Respndents t a 2009 TechInsights survey claimed that 57% f their prjects were cmpleted late, n average finishing 4.4 mnths behind schedule. Wrking in an industry that develps safety-critical prducts is n prtectin against the ecnmic cnditins ravaging the ecnmy. Sme industries are mre sensitive t ecnmic fluctuatins than thers are. One example wuld be private aircraft manufacturing. The impact is nt limited t small aircraft manufacturers; it trickles dwn t the instrument, radi, grund-based equipment and facilities, etc. S, like everyne else, safety-critical develpers are being asked t d mre with less and cut every dime f expense. Fr develpers in medicine, industry, avinics, and transprtatin this culd nt have cme at a wrse time. Fr, unlike their brethren develping cmmercial grade sftware, safety-critical develpers wh cut crners, r hack a bug fix, may have t live with dire cnsequences f their actins. Develpers have Optins The additin f an RTOS brings many benefits t the develper. Prtability, reusability and a superir prgramming mdel are just a few f the immediate benefits. The additin f majr feature sets, such as netwrking and cnnectivity stacks, graphical user interfaces, and file systems, can be added with little difficulty t help ffset feature-based demands frm the field. Hwever, the additin f an RTOS kernel, alng with advanced sftware stacks, als has the ptential t drive its certificatin csts beynd the budget at which a manufacturer can make a reasnable return n their investment. This is where VSC and Micriµm fill the vid. Micriµm with VSC's backing deliver integrated netwrking, USB, and fault-tlerant file systems, and deliver them with cmplete certificatin supprt. Furthermre, Micriµm has made an art f wrking with semicnductr vendrs t make µc/os available t their custmers. With VSC's certificatin supprt added t the mix, medical, avinics, industrial and transprtatin applicatin develpers are able t rder certificatins as easily as they rder their hardware and sftware, and t d s with the knwledge that it will arrive ready t submit t any f the majr regulatry agencies arund the glbe. Meet Validated Sftware and Micriµm Over the last decade, Micriµm and Validated Sftware (VSC) have wrked tgether t prvide cst effective safety-critical sftware and its supprting certificatin artifacts s that their Cpyright 2010, Validated Sftware Crpratin Page 8 f 11

9 custmers did nt have t divert their fcus frm the features that differentiate their prducts frm their cmpetitrs. With their custmer-centric rientatin, bth cmpanies have cultivated a reputatin fr delivering high-value prducts withut any fuss r hassles. Develped specifically fr resurce cnstrained embedded devices, Micriµm s µc/os embedded cmpnents are used in millins f devices wrldwide, and include numerus designs in building and industrial cntrl and autmatin, medical devices, avinics, rail and transprtatin devices, and a variety f ther missin, and safety-critical applicatins. VSC cmpliments Micriµm s efficient RTOS cde with its semi-custm, certificatin ready Validatin Suites and ff the shelf Validatin Kits. VSC's stated missin is t reduce risk; they d s with a practical and cmprehensive apprach t develping and delivering their validatin prducts with an unheard f guarantee that the cmpnents they supprt will receive certificatin. In tday's ecnmy, cmpanies can n lnger pay a premium withut receiving equal value in return. With Micriµm and VSC annuncing their frmal cmmitment t a strategic alliance, custmers f bth cmpanies can expect t receive faster service, greater alignment n radmaps, and better service due t increased scale. Micriµm Micriµm is a leader in embedded sftware cmpnents. The cmpany's flagship µc/os family is recgnized fr a variety f features and benefits including unparalleled reliability, perfrmance, dependability, impeccable surce cde, and vast dcumentatin. In additin, several Micriµm mdules cntain certificatins that meet the rigrus safety-critical standards demanded by several industries. Bth Micriµm funder Jean Labrsse and Micriµm vice-president Christian Legare are widely knwn and respected as industry experts based upn their brad visibility within the industry. In additin t the educatinal tracts they deliver at Embedded System Cnferences and ther industry events, Jean's bks n RTOS are the mst ppular bks n the subject, and have been used by mst embedded system develpers since their cllege days. Micriµm prducts are created fr engineers by engineers. If yu are new t Micriµm, cntact them t discuss yur prject requirements, challenges, and gals. Let them shw yu hw their cmmercial RTOS family prvides time-t-market advantages at a price yu can affrd. Micriµm will shw yu hw their sftware mdule advantages translate int substantial time and resurce savings tday and in the future. Validated Sftware VSC has been develping embedded safety-critical sftware and its supprting evidence f standards cmpliance (certificatin artifacts) fr ver ten years. VSC supprts every cmmercial 16 and 32-bit prcessr and tlset that µc/os supprts, and VSC s cre cmpetency is prviding certificatin supprt fr embedded COTS RTOS cmpnents. Nt nly is VSC uniquely qualified t prvide certificatin artifacts fr µc/os, its internal systems and prcess are tuned t d s with the least pssible expense. VSC has develped certificatin packages that have enabled device certificatin fr the dminant internatinal safety-critical sftware standards used in aviatin, medical, industrial, and building autmatin, and transprtatin. In additin, with advanced ntice, VSC can rapidly satisfy many derivatins used in sme f the smaller niche markets. In additin t expertise in RTOS kernels, memry management units, cmmunicatin and file system sftware verificatin and validatin, VSC prvides a brad range f prfessinal services including BSP and firmware develpment, run-time library validatin and cmpiler qualificatin. Cpyright 2010, Validated Sftware Crpratin Page 9 f 11

10 VSC als trains and mentrs sme f the largest cmpanies in the wrld n certificatin and cmpliance strategies. VSC guarantees its prducts; any sftware cmpnents that it supprts are 100% cmpliant with relevant standards and WILL receive certificatin. VSC has never had a prject fail, r a prject canceled due t use f its prducts. Furthermre, VSC s COTS based pricing and licensing apprach t safety-critical develpment cnsistently brings its ffering t market at a fractin f the price f its cmpetitrs. µc/os Sftware and Certificatin Ready Evidence VSC prvides tw tiers f certificatin prducts fr Micriµm s µc/os real-time perating system, Validatin Suites, and Validatin Kits. Validatin Suites are the gld standard f certificatin supprt. Frm an ease f use perspective, a Validatin Suite requires zer effrt n the custmer s part. Each Validatin Suite is delivered running and tested n the evaluatin hardware selected by the end custmer. When it is time t apply fr device certificatin, ne simply references the Validatin Suite in the master dcument set and includes a cpy f the Validatin Suite with their system submissin. The μc/os kernel* has tw parts, a Cre cmpnent (~90%), and a Prt cmpnent (~10%). The cre sftware cmpnent prvides the µc/os kernel services and API s that are used by the applicatin sftware. The cre μc/os sftware is static (hardware and cmpiler agnstic) and nly changes due t planned updates and enhancements. The µc/os prt sftware cmpnent is the hardware abstractin layer that binds the cre µc/os sftware t the hardware. The µc/os kernel is extremely prtable and can be used with mst 16 and 32-bit prcessrs, DSPs, and FPGA sftcres simply by adapting the µc/os prt sftware t the new hardware and tlset (cmpiler). μc/os Kernel Cre Sftware Apprximately 90% f the µc/os kernel sftware Cntains all the μc/os Kernel API s and services Abstracted away frm hardware and tls Des nt change frm target t target μc/os Kernel Prt Sftware Apprximately 10% f the µc/os kernel sftware Glue-layer between the hardware and the μc/os Kernel Cre sftware Dependent n hardware and tls Changing tls r hardware requires changes t prt sftware Similarly, the Validatin Suite has bth a cre and a prt cmpnent. Like the µc/os kernel, apprximately ninety percent f the cre Validatin Suite is static; it nly changes in respnse t updates, and enhancements made t the cre µc/os sftware. The cre f the Validatin Suite represents ver sixteen persn-mnths f expert develpment effrt. Like the µc/os kernel cre, it is agnstic t bth the hardware and the tlset. Equally prtable, Validatin Suites can be prted t supprt µc/os certificatin n almst any hardware and sftware. T create a custm Validatin Suite, the Validatin Suite prt is mdified in supprt f the µc/os prt (prt hardware). Reliability and accuracy is ensured by using same hardware target, tlset, µc/os sftware versin and the prt sftware that is used in the end device. The results f the PST i.e. unit test results, integratin test results and related test items are then cllected and summarized. Prject checklists, test reprts, and all dcumentatin are examined fr crrectness and dcumented with VSC signff signatures. All supprting evidence is packaged Cpyright 2010, Validated Sftware Crpratin Page 10 f 11

11 i.e., safety manual, sftware accmplishments summary, trace matrix, and all ther relevant items required t cmplete the Validatin Suite. In additin t interim deliveries that may have been made during the prject, the final Validatin Suite DVD is created and delivered via bnded pstal service. Validatin Kits are fr custmers wh desire t d final testing and gather their results in their wn facility. Unlike the Validatin Suites, Validatin Kits d nt prvide the certificatin evidence based n the final hardware target. The custmer prts the Validatin Kit t their hardware, then executes their test cde and gathers the results. This is the same exact prcess that VSC uses when they develp a Validatin Suite. As shipped, each Validatin Kits represents apprximately 90% (~16 man-mnths) f the ttal µc/os cmpnent certificatin effrt. VSC has Kits and Suites that supprt µc/os-ii (and the prducts belw) certificatin in fr the fllwing markets and standards: RTCA DO-178C, DO-278A, EUROCAE ED-12C, ED-109A Avinics (Airbrne) IEC Industrial cntrl, autmatin, manufacturing, safety systems UL-1998 Hme, cnsumer, industrial safety IEC Medical, clinical and hme diagnstic and therapy FDA/CDRH 510(k) Medical clinical and hme diagnstic and therapy CENELEC EN Rail/transprtatin, lcmtive, signaling, and cntrl (fr a full list f supprt please cntact VSC at inf@validatedsftware.cm) When facing the decisin t use in-huse resurces t develp the afrementined prducts, cnsider the cntinuus investment made by bth Micriµm and VSC in their prduct lines. The initial investment represents man-decades. Then cnsider the number f users and devices in which their prducts have been prven in ver the last decade. Finally cnsider the wisdm f using precius resurces t develp cmmdity infrastructure when they can be used t add the special sauce that makes yur cmpany successful tday. The wrld f the embedded engineer has becme a much mre stressful, and cmplicated place. Micriµm and Validated Sftware can shw yu hw t reduce yur risk and imprve yur time t market with their cst effective RTOS and certificatin prducts. Visit Validated Sftware.cm fr the latest prduct infrmatin. Fr mre infrmatin abut µc/os-ii, refer t Fr mre infrmatin abut the Validatin Suite, see Cmplete prduct infrmatin, including sample f each DO-178C dcument in the Validatin Suite can be requested frm the Validated Sftware Sales ffice. Sales@ValidatedSftware.cm Validated Sftware Crpratin. All rights reserved. This dcument cntains infrmatin that is prprietary t Validated Sftware Crpratin and may be duplicated in whle r in part by the riginal recipient fr internal business purpses nly, prvided that this entire ntice appears in all cpies. In accepting this dcument, the recipient agrees t make every reasnable effrt t prevent unauthrized use f this infrmatin. Cpyright 2010, Validated Sftware Crpratin Page 11 f 11