software guide – new approach

Software Guide – New Approach

CECIP-Concept

CECIP Subgroup Software

18.07.2014 CECIP Software Guide – New Approach

Agenda1. Today’s situation

2. Aim

3. WELMEC Software Guides

4. Limits of WELMEC Guides

5. State of the Art - 2014

6. The New Approach1. Development Processes

2. Essential Properties and Criteria

3. Risk Managment


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 No smartphones in use any more?

2030 WELMECGuide 7.2 Rev. 6 … .

World changes very fast prognoses are always difficult


1. Todays situationArchitecture

Back Bone

Data Storage

POS

Client Appl.

(Smartphone)Weight cells

output: weight and calculated pricealternative: incl. display / printer

POS :display of the ticket

incl. price and weight

Customer 1 terminal

data transmission of the ticket incl. price

and weight

supervision of the HW not possible (virtual cluster)


System architecture: todays possible POS SystemBrief 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)


Architecture

Weight calculation

Weight- Data-Server

Client Appl.

Weight cellsoutput: digital signal + calibration data

Weight calculation (calculating sensor signals with calibration data and sum signaloutput: weight

Customer 1 appl: Calculation of Net-Weight, price calculation ....

Weight data server

Customer 2 appl: Calculation of Net-

Weight, price calculation ....

Customer n appl: Calculation of Net-

Weight, price calculation ....

Customer 1 terminal

Integrity of the calculation module o.k.

supervision of the HW not possible (virtual cluster)


System architecture: truck scale-service

Brief description of the system:

o Truck scale service for usage by different carriers

o Usage of current existent technologies: Digital Sensors, Cloud services, Local and Web based user applications

o Single weighing point, distributed data usage

o different applications on single system under legal control (customer has their own system for e.g. price calculation)


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)

- .....


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


2. Aim – flexible criterias for 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


WELMEC Software Guides - Guide 2.31994

Basic Principle: Describe essential properties, rather than technical solutions

Differentiation of legally relevant and other SW 5 basic functionalities identifed

Single distinct instrument with one "PC"


WELMEC Software Guides - Guide 7.1 < 2000

Two typical instruments discussed: Example A: Standalone Instrument (P)

Example B: PC-based Instrument

- Modular System: Sensor(s), "PC", HMI-Devices

- Closed and open networks

Software Download


WELMEC Software Guides - Guide 7.22004

The Guide is limited to the two examples described in Guide 7.1: (P) and (U) Specific requirements and focus on technical

solutions Since then only piecemeal changes

Basic

P/U

SW-download

Data Trans-missio

n

Data Storage

SW-Separatio

n


Limits of actual WELMEC Software Guides Concept of one Instrument based on one individual identifiable

"PC": status of year 2000. Approach to cover all options with two configurations. Compilation of technical scenarios and acceptable solutions.

Actual use cases not covered. State of the art technologies and environment not reflected.

Market Surveillance feels, that present concepts are incomplete and confusing.


State of the Art – 2014 Users needs: up to date technologies, fit to actual

environment, user-friendliness, timeliness, adequate price

Technologies: simple standalone devices, but additionally: Intelligent Hardware (HW) with software modules operated by

several processors Web- & cloud- based instruments HW-configuration on demand (e.g. mobiles, tablets) Intelligent automatic SW-installation, - protection, -

authentification, - authorisation Remote maintenance & service Continous development of HW- & SW- environment


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


The New Approach – Target: improve trust in SW

Re-widen the scope of scenarios (from P/U) to others and include todays and future growing range of options and configurations.

Move from compiling specific solutions and go back to basic requirements (capable to cover future developments, whereas technical solutions can't).

Provide processes and procedures to the manufacturers to develop new solutions in a transparent, reliable, state of the art and feasible manner.

Provide tools to the manufacturers

to fulfill traceably and risk-based essential requirements and

to identify consitently the impacts of changes to software.


The new Approach – Concept

Characterise and standardise SW-Development

1. Identify minimum requirements for development and production processes

2. Specify basic requirements and risk based criteria for Software

Resulting in a uniform basis for records for module B, D and F


1. SW-Development Processes e.g. GAMP 5 "A Risk Based Approach to Compliant GxP Computerized Systems"

Target of GAMP 5: Manufacturers good practices Defines critieria for manufacturers of software to facilitate the

capability to validate the application of the software.

Translation to Legal Metrology:Defines criteria for manufacturers of software to facilitate the capability to validate conformity to essential requirements and conformity to type of the application of the software (i.e. the instruments).


Essential

Require-

ments• Dir

ectives

Software

Development

Software

• Executable Software

• Installation & user manual

• Conformity assessment Plan

Handover to manuf

ac-turing

Conformity

assessment

• Record

• DoC

Use

ModuleB

ModuleD/F

Basic Concept of GAMP 5

Translation to Legal Metrology

Require-

ments

Software

Development

Software

• Executable Software

• Installation & userdocumentation

• Validation

Plan

Handover to customer

Validation

(IQ/OQ/PQ)

• Validation

record

Use

Validation can't be done without information about the

Software-Development


GAMP 5 - Elements for Development Processes

Quality Management System

Requirements

Quality Plannin

gSubsup

-plier Management

Specifi-cations

Review

SW-Produc

-tion (Implementation)

Testing

Release

Risk Management

Documentation & Archiving

Change Management


GAMP 5 Elements for Development Processes

Documentation & Archiving

Quality Management System

Requirement

s

Quality Planni

ngSubsup-plier Manage-ment

Specifi-

cations

Review

SW-Produc-tion (Implementat

ion)

Testing

Release

Risk Management

Change Management

Software•Executable Software•Installation & user manual•Validation Plan


Conformity Assessment Plan:

Software•Executable Software•Installation & user manual•Conformity Assess-ment Plan

Is developed by the manufacturer during the developement process

Is assessed by the notified body Module B during the Type Evaluation

Is used by the manufacturer (Module D) and/or notified body (Module F) to verify accurate/authentic software and correct functioning.

Is used by the market surveillance to check conformity to type

Translation to Legal Metrology


Conformity Assessment Plan (Module B)

Risk based: identifies critical risk factors mitigated related to proper installation and configuration to the individual instrument.

Identifies required:

1. Quality Assurance Procedures (manufacturing parameters)(e.g.: Check of software installation records, to be done in the factory by the manufacturer)

2. Quality Control Procedures (tests)(e.g.: Check of status information displayed on site by manufacturer/notified body)


Conformity Assessment (Module D/F)Check of complete and accurate execution of the Conformity Assessment Plan

Module D: Surveillance of Manufacturing Phase Module F: Review of available records defined in the Conformity

Assessment Plan and execution of remaining defined tests.

Market Surveillance (risk based approach and escalation)1. Checks of on-site evidence for conformity

2. Confirmation of identity basing on TEC

3. Detailed tests and review in conjunction with manufacturer


Legal Functionalities

Basic Unite.g.

standalone Instr.,

or Loadcell

e.g.Display

e.g. Storage

2. Basic Properties & Criteria: Risk based Approach

Type of Modules

identified & protected Entity

Virtual Entity

Type of Transactions:

Within basic Unit

Basic Unit – identified Entity

Basic Unit – virtual Entity

Identified Entity – identified Entity

Identified Entity – virtual Entity

Virtual Entity – virtual Entity


3. Risk Management (e.g.): GAMP 5 ISO 31'000's EN 14971 WELMEC 5.3

Basic Elements of Risk Management

Hazard

Identifi-

cation

Risk Analysis

Risk Evalua-tion

Risk mitigation

Risk Evalua-tion

Final Risk Repo

rt


Invitation to next steps

Basis: Examples shown are for illustration purposes, details are subject to future work.

Conceptual review by all members of the informal group

Consolidate common approach

Collaborate on a common concept

Thank you

software guide – new approach

Documents