Software Guide – New Approach

1. Software Guide – New Approach CECIP-Concept CECIP Subgroup Software

2. Agenda • Today’ssituation • Aim • WELMEC Software Guides • Limits of WELMEC Guides • State ofthe Art - 2014 • The New Approach • Development Processes • Essential Properties andCriteria • RiskManagment

3. Prognoses in the 90th? 2003 Arnold Schwarzenegger: Governor of California and re-elected 2004 Latvia: EU country; 1990 the country didn’t exist … • Prognoses from todays point of view? 2030 Angela Merkel reelected as German Kanzler? 2030 Oligarch to buy FC Bayern? 2030 Nosmartphonesin useanymore? 2030 WELMECGuide7.2 Rev. 6 … . • World changes very fast • prognoses are always difficult

4. Todayssituation • Architecture supervision of the HW not possible (virtual cluster) POS :display of the ticket incl. price and weight Back Bone Data Storage POS data transmission of the ticket incl. price and weight Client Appl. (Smartphone) Weight cellsoutput: weight and calculated pricealternative: incl. display / printer Customer 1 terminal

5. System architecture: todays possible POS System Brief description of the system: - Weighing Cells digital - Usage of current existent technologies: Digital Sensors, Cloud services, Local and Web based user applications - Single weighing point, distributed data usage - different applications on single system under legal control (customer has their own system for e.g. price calculation)

6. Architecture Customer 2 appl: Calculation of Net-Weight, price calculation .... Weight calculation (calculating sensor signals with calibration data and sum signaloutput: weight Weight data server Weight- Data-Server Weight calculation Integrity of the calculation module  o.k. supervision of the HW not possible (virtual cluster) Client Appl. Customer n appl: Calculation of Net-Weight, price calculation .... Customer 1 appl: Calculation of Net-Weight, price calculation .... Weight cellsoutput: digital signal + calibration data Customer 1 terminal

7. System architecture: truck scale-service • Brief description of the system: • Truck scale service for usage by different carriers • Usage of current existent technologies: Digital Sensors, Cloud services, Local and Web based user applications • Single weighing point, distributed data usage • different applications on single system under legal control (customer has their own system for e.g. price calculation)

8. Questions • - What are legal relevant components ? • - How to fulfill essential requirements? • - How to approve different user applications (single approval or one for all)? • - How to describe the system under WELMEC 7.2? • - How to supervise the virtual cluster (without dedicated HW) • - .....

9. Comments • - Welmec Guide 2.3  no possible technical scenario to get an approval • - Welmec Guide 7.2 Rev. 6: - Risk class D for the whole system because of wireless data transmission Table 7-1: Technical description of communication networks extract: Any network that contains legally controlled devices with infrared or wireless network communications interfaces shall be considered to be an open network. In open networks the risk of manipulation of transmitted data is high and the transmission has to be classified to risk class D. Because the protection means are realised in the end devices of the transmission channel Conflict: there is no Weighing Instrument available to fulfill risk class D

10. 2. Aim – flexible criteriasfor different innovative architectures • risk based approach as a possible solution • risk management of each interface • process controlled realization of the development and type approval • safe data transmissions, sw-signature, encryption... can taken into account • Welmec Guide 2.3 1994 • Welmec Guide 7.1 2000 • Welmec Guide 7.2 2004... • .... • Welmec Guide XYZ 2030

11. WELMEC Software Guides - Guide 2.3 1994 • Basic Principle: Describe essential properties, ratherthantechnicalsolutions • Differentiation oflegally relevant andother SW • 5 basicfunctionalitiesidentifed • Single distinctinstrumentwithone "PC"

12. WELMEC Software Guides - Guide 7.1 < 2000 Twotypicalinstrumentsdiscussed: • Example A: Standalone Instrument (P) • Example B: PC-based Instrument - Modular System: Sensor(s), "PC", HMI-Devices - Closedand open networks • Software Download

13. WELMEC Software Guides - Guide 7.2 2004 The Guide is limited tothetwoexamplesdescribed in Guide 7.1: (P) and (U) • Specificrequirementsandfocus on technicalsolutions • Sincethenonlypiecemealchanges

14. Limits ofactual WELMEC Software Guides • Conceptofone Instrument based on one individual identifiable "PC": statusofyear 2000. • Approach tocover all optionswithtwoconfigurations. • Compilationoftechnicalscenariosandacceptablesolutions. • Actualusecases not covered. • State ofthearttechnologiesandenvironment not reflected. • Market Surveillancefeels, thatpresentconceptsareincompleteandconfusing.

15. State ofthe Art – 2014 • Users needs: uptodatetechnologies, fit toactualenvironment, user-friendliness, timeliness, adequateprice • Technologies: simple standalonedevices, but additionally: • Intelligent Hardware (HW) withsoftwaremodulesoperatedbyseveralprocessors • Web- & cloud- basedinstruments • HW-configuration on demand (e.g. mobiles, tablets) • Intelligent automatic SW-installation, - protection, - authentification, - authorisation • Remote maintenance & service • Continousdevelopmentof HW- & SW- environment

16. Examples: • weighbridges that are connected to the cloud and the weighing result is sent to a mobile by means of a SMS: already approved • Software-use, storage capacities and printers are rented by the users from manufacturers (Pay per use). • Virtual services (including price calculation) can continuously update software (like Adobe is doing with Adobe Cloud or Microsoft with Office 365) • On demand pairing to the consumer's display (i.e. his smart phone or tablet).

17. The New Approach – Target: improvetrust in SW • Re-widenthescopeofscenarios (from P/U) toothersandincludetodaysandfuturegrowingrangeofoptionsandconfigurations. • Move fromcompilingspecificsolutionsandgo back tobasicrequirements (capabletocoverfuturedevelopments, whereastechnicalsolutionscan't). • Provideprocesses and procedures to themanufacturers to developnewsolutions in a transparent, reliable, stateoftheart and feasiblemanner. • Providetools to themanufacturers • tofulfilltraceablyandrisk-based essential requirementsand • toidentifyconsitentlytheimpacts of changes to software.

18. The new Approach – Concept Characteriseandstandardise SW-Development • Identifyminimumrequirementsfordevelopmentandproductionprocesses • Specifybasicrequirementsandriskbasedcriteriafor Software Resulting in a uniform basisforrecordsformodule B, D and F

19. SW-Development Processese.g. GAMP 5 "A RiskBased Approach toCompliantGxPComputerized Systems" • Target of GAMP 5: Manufacturersgoodpractices • Definescritieriaformanufacturersofsoftwaretofacilitatethecapabilitytovalidatetheapplicationofthesoftware. • Translation to Legal Metrology:Definescriteriaformanufacturersofsoftwaretofacilitatethecapabilitytovalidateconformitytoessential requirementsandconformityto type oftheapplicationofthesoftware (i.e. theinstruments).

20. Validation can'tbedonewithoutinformationabouttheSoftware-Development Basic Conceptof GAMP 5 Translation to Legal Metrology ModuleB ModuleD/F

21. GAMP 5 - Elements for Development Processes Quality Management System Risk Management Documentation & Archiving Change Management

22. Software • Executable Software • Installation & usermanual • Validation Plan • GAMP 5 Elements for Development Processes Quality Management System Risk Management Documentation & Archiving Change Management

23. Software • Executable Software • Installation & usermanual • ConformityAssess-ment Plan Translation to Legal Metrology • ConformityAssessment Plan: • Isdevelopedbythemanufacturerduringthedevelopementprocess • Isassessedbythenotifiedbody Module B duringthe Type Evaluation • Isusedbythemanufacturer (Module D) and/ornotifiedbody (Module F) toverifyaccurate/authenticsoftwareandcorrectfunctioning. • Isusedbythemarketsurveillanceto check conformityto type

24. Conformity Assessment Plan (Module B) • Riskbased: identifiescriticalriskfactorsmitigatedrelatedto proper installationandconfigurationtothe individual instrument. • Identifiesrequired: • Quality Assurance Procedures (manufacturingparameters)(e.g.: Check ofsoftwareinstallationrecords, tobedone in thefactorybythemanufacturer) • Quality Control Procedures (tests)(e.g.: Check ofstatusinformationdisplayed on sitebymanufacturer/notifiedbody)

25. Conformity Assessment (Module D/F) Check ofcompleteandaccurateexecutionoftheConformity Assessment Plan • Module D: Surveillanceof Manufacturing Phase • Module F: Review ofavailablerecordsdefined in theConformity Assessment Plan andexecutionofremainingdefinedtests. Market Surveillance(riskbasedapproachandescalation) • Checks of on-site evidenceforconformity • Confirmationofidentitybasing on TEC • Detailedtestsandreview in conjunctionwithmanufacturer

26. Type ofModules • identified & protectedEntity • Virtual Entity Type of Transactions: • Withinbasic Unit • Basic Unit – identified Entity • Basic Unit – virtual Entity • Identified Entity – identified Entity • Identified Entity – virtual Entity • Virtual Entity – virtual Entity • Basic Properties & Criteria: Riskbased Approach

27. Risk Management (e.g.): • GAMP 5 • ISO 31'000's • EN 14971 • WELMEC 5.3 Basic Elements ofRisk Management

28. Invitation tonextsteps Basis: Examplesshownareforillustrationpurposes, detailsaresubjecttofuturework. • Conceptualreviewby all membersofthe informal group • Consolidatecommonapproach • Collaborate on a commonconcept

29. Thank you