sysa-13-03-20 (1)

8/19/2019 sysa-13-03-20 (1)

1/36

sysa/13-03-13 RFP Template: ab/13-03-01

Object Management Group

109 Highland Avenue

Needham, MA 02494

USA

Telephone: +1-781-444-0404

Facsimile: +1-781-444-0320

[email protected]

Dependability Assurance Framework

For Safety-Sensitive Consumer Devices

Request For Proposal

OMG Document: sysa/13-03-20

Letters of Intent due: 21st June 2013

Submissions due: 11th November 2013

Objective of this RFP

The term “Safety-Sensitive Consumer device” (SSCD) refers to a category of

industrial products used by consumer users, including automobiles, service

robots, medical devices and clinical systems, and smart houses !nli"e traditional

industrial machinery, such consumer devices must be dependable because they are

used in diverse, open and dynamic environments #here the need for safety,reliability and even availability of such devices is no longer an option but a

re$uirement The challenge is to develop a solution that satisfies this

dependability re$uirement in cost-efficient #ay, preserving the affordable prices

of SSCDs for the mass-mar"et

Dependability Assurance Fwk For SSCDs RFP 24 March 2016 1

8/19/2019 sysa-13-03-20 (1)

2/36


% Dependability %ssurance &rame#or" (D%&) e'tends engineering approaches

#ith additional vie#points describing the assurance case, conceptual model for

describing properties and process models This #ould allo# us to ustify given

properties throughout engineering processes by using e'plicit argumentation and

evidence

The obective of this &* is to produce a specification for building ustifiably

dependable SSCDs by specifying+

ne or more Dependability Conceptual .odels (DC.s) defining the factors

of dependability,

/ ne or more templates to be used to construct Dependability %ssurance

Cases (D%Cs) for SSCDs, and

0 ne or more Dependability *rocess .odels (D*.s) that define rapid and

iterative processes for engineering dependable SSCDs

The response is e'pected to include generic customi1able templates for D%C, as

#ell as generic models for DC. and D*., all supported by specific e'amples

&or further details see Chapter 2 of this document

1 Introduction

1.1Goals of OMG

The bect .anagement 3roup (.3) is a soft#are consortium #ith an

international membership of vendors, developers, and end users 4stablished in

565, its mission is to help computer users solve enterprise integration problems

by supplying open, vendor-neutral portability, interoperability and reusability

specifications based on .odel Driven %rchitecture (.D%) .D% defines an

approach to 7T system specification that separates the specification of system

functionality from the specification of the implementation of that functionality on

a specific technology platform, and provides a set of guidelines for structuring

specifications e'pressed as models .3 has published many #idely-used

specifications such as !.8 9!.8:, ;*.< 9;*.

8/19/2019 sysa-13-03-20 (1)

3/36


Section / > Architectural Context ;ac"ground information on .3?s .odel

Driven %rchitecture

Section 0 > Adoption Process ;ac"ground information on the .3

specification adoption process

Section @ > Instructions for Submitters 4'planation of ho# to ma"e a

submission to this &*

Section A > General Requirements on Proposals e$uirements and evaluation

criteria that apply to all proposals submitted to .3

Section 2 > Specific Requirements on Proposals *roblem statement, scope of

proposals sought, mandatory re$uirements, non-mandatory features, issues to be

discussed, evaluation criteria, and timetable that apply specifically to this &*

%ppendi' % > eferences and 3lossary Specific to this &*

%ppendi' ; > 3eneral eferences and 3lossary

1.3Conventions

The "ey #ords "shall", "shall not", "should", "should not", "may" and

"need not" in this document should be interpreted as described in *art / of the

7SB74C Directives 97S/: These 7S terms are compatible #ith the same terms

in 74T& &C /5 9&C/5:

1.4Contact Information

uestions related to .3?s technology adoption process and any $uestions

about this &* should be directed to [email protected]

.3 documents and information about the .3 in general can be obtained

from the .3?s #eb site+ http://www.omg.org Templates for &*s (li"e this

document) and other standard .3 documents can be found on the Template

Do#nloads *age+ http://www.omg.org/technology/template_download.htm

2 Architectural Context

.D% provides a set of guidelines for structuring specifications e'pressed as

models and the mappings bet#een those models The .D% initiative and the

standards that support it allo# the same model, specifying business system or

application functionality and behavior, to be reali1ed on multiple platforms .D%

enables different applications to be integrated by e'plicitly relating their models


8/19/2019 sysa-13-03-20 (1)

4/36


this facilitates integration and interoperability, and supports system evolution

(deployment choices) as platform technologies change The three primary goals

of .D% are portability, interoperability and reusability

*ortability of any subsystem is relative to the subsystems on #hich it depends

The collection of subsystems that a given subsystem depends upon is oftenloosely called the platform, #hich supports that subsystem *ortability > and

reusability > of such a subsystem is enabled if all the subsystems that it depends

upon use standardi1ed interfaces (%*7s) and usage patterns

.D% provides a pattern comprising a portable subsystem that is able to use any

one of multiple specific implementations of a platform This pattern is repeatedly

usable in the specification of systems The five important concepts related to this

pattern are+

Model > % model is a representation of a part of the function, structure andBor

behavior of an application or system % representation is said to be formal#hen it is based on a language that has a #ell-defined form (“synta'”),

meaning (“semantics”), and possibly rules of analysis, inference, or proof for

its constructs The synta' may be graphical or te'tual The semantics might

be defined, more or less formally, in terms of things observed in the #orld

being described (eg message sends and replies, obect states and state

changes, etc), or by translating higher-level language constructs into other

constructs that have a #ell-defined meaning The (non-mandatory) rules of

inference define #hat unstated properties can be deduced from e'plicit

statements in the model 7n .D%, a representation that is not formal in this

sense is not a model Thus, a diagram #ith bo'es and lines and arro#s that is

not supported by a definition of the meaning of a bo', and the meaning of aline and of an arro# is not a model > it is ust an informal diagram

/ Platform > % set of subsystemsBtechnologies that provide a coherent set of

functionality through interfaces and specified usage patterns that any

subsystem that depends on the platform can use #ithout concern for the

details of ho# the functionality provided by the platform is implemented

0 Platform Independent Model (PIM) > % model of a subsystem that contains

no information specific to the platform, or the technology that is used to

reali1e it

@ Platform Specific Model (PSM) > % model of a subsystem that includes

information about the specific technology that is used in the reali1ation of that

subsystem on a specific platform, and hence possibly contains elements that

are specific to the platform


8/19/2019 sysa-13-03-20 (1)

5/36


A Mapping > Specification of a mechanism for transforming the elements of a

model conforming to a particular metamodel into elements of another model

that conforms to another (possibly the same) metamodel % mapping may be

e'pressed as associations, constraints, rules or templates #ith parameters that

to be assigned during the mapping, or other forms yet to be determined

.3 adopts standard specifications of models that e'ploit the .D% pattern to

facilitate portability, interoperability and reusability, either through ab initio

development of standards or by reference to e'isting standards Some e'amples

of .3 adopted specifications are+

ang!age" > eg 7D8 for interface specification 97D8:, !.8 for model

specification 9!.8:, ;*.< for ;usiness *rocess specification 9;*. eg eg 37*B77* 9C;%: (both structure and e'change

protocol), DDS 7nteroperability *rotocol 9DDS7:

2 $omain Specific Standard" > eg .odel for *erformance-Driven

3overnment 9.*3:, Single

8/19/2019 sysa-13-03-20 (1)

6/36


3 Adoption Process

3.1Introduction

.3 decides #hich specifications to adopt via votes of its .embership Thespecifications selected should satisfy the architectural vision of .D% .3

bases its decisions on both business and technical considerations nce a

specification is adopted by .3, it is made available for use by both .3

members and non-members ali"e, at no charge

This section 0 provides an e'tended summary of the &* process &or more

detailed information, see the Policie" and Proced!re" of the %M& 'echnical

Proce"" 9*F*:, specifically Section @/, and the %M& itchhier*" &!ide

93uide: 7n case of any inconsistency bet#een this document or the Gitchhi"erHs

3uide and the *olicies and *rocedures, the *F* is al#ays authoritative %ll 7*-

related matters are governed by .3Hs Intellect!al Property +ight" Policy 97*:

3.2The Adoption Process in detail

3.2.1 Development and Issuance of RFP

&*s, such as this one, are drafted by .3 .embers #ho are interested in the

adoption of an .3 specification in a particular area The draft &* is presented

to the appropriate T&, discussed and refined, and #hen ready is recommended for

issuance 7f endorsed by the %rchitecture ;oard, the &* may then be issued as

an .3 &* by a TC vote

!nder the terms of .3Hs 7ntellectual *roperty ights *olicy 97*:, every &*

shall include a statement of the 7* .ode under #hich any resulting specification

#ill be published To achieve this, &* authors choose one of the three allo#able

7* modes specified in 97*: and include it in the &* > see section 2I

3.2.2 Letter of Intent (LOI)

4ach .3 .ember organisation that intends to ma"e a Submission in response

to any &* (including this one) shall submit a 8etter of 7ntent (87) signed by an

officer on or before the deadline specified in the &*Hs timetable (see section

2) The 87 provides public notice that the organisation may ma"e a

submission, but does not oblige it to do so

3.2.3 Voter Registration

%ny interested .3 .embers, other than Trial, *ress and %nalyst members, may

participate in Tas" &orce voting related to this &* 7f the &* timetable includes


8/19/2019 sysa-13-03-20 (1)

7/36


a date for closing the voting list (see section 2), or if the Tas" &orce separately

decides to close the voting list, then only .3 .ember that have registered by

the given date and those that have made an 7nitial Submission may vote on Tas"

&orce motions related to this &*

.ember organi1ations that have submitted an 87 are automatically registered tovote in the Tas" &orce Technical Committee votes are not affected by the Tas"

&orce voting list > all Contributing and Domain .embers are eligible to vote in

DTC polls relating to DTC &*s, and all Contributing and *latform .embers are

eligible to vote in *TC polls on *TC &*s

3.2.4 Initial Submissions

7nitial Submissions shall be made electronically on or before the 7nitial

Submission deadline, #hich is specified in the &* timetable (see section 2),

or may later be adusted by the Tas" &orce Submissions shall use the .3

specification template 9T.*8:, #ith the structure set out in section @5 7nitialSubmissions shall be #ritten specifications capable of full evaluation, and not ust

a summary or outline Submitters normally present their proposals to the Tas"

&orce at the first T& meeting after the submission deadline .a"ing a submission

incurs obligations under .3Hs 7* policy > see 97*: for details

%n 7nitial Submission shall not be altered once the 7nitial Submission deadline has

passed The Tas" &orce may choose to recommend an 7nitial Submission,

unchanged, for adoption by .3 ho#ever, instead Tas" &orce members usually

offer comments and feedbac" on the 7nitial Submissions, #hich submitters can

address (if they choose) by ma"ing a later evised Submission

The goals of the Tas" &orceHs Submission evaluation are+

• *rovide a fair and open process

• &acilitate critical revie# of the submissions by .3 .embers

• *rovide feedbac" to submitters enabling them to address concerns in their

revised submissions

• ;uild consensus on acceptable solutions

• 4nable voting members to ma"e an informed selection decision

Submitters are e'pected to actively contribute to the evaluation process

3.2.5 Revised Submissions

evised Submissions are due by the specified deadline evised Submissions

cannot be altered once their submission deadline has passed Submitters again


8/19/2019 sysa-13-03-20 (1)

8/36


normally present their proposals at the ne't meeting of the T& after the deadline

7f necessary, the Tas" &orce may set a succession of evised Submission

deadlines Submitters choose #hether or not to ma"e evised Submissions - if

they decide not to, their most recent Submission is carried for#ard, unless the

Submitter e'plicitly #ithdra#s from the &* process

The evaluation of evised Submissions has the same goals listed above

3.2.6 Selection Votes

Jhen the Tas" &orceHs voters believe that they sufficiently understand the relative

merits of the available Submissions, a vote is ta"en to recommend a submission

to the Tas" &orceHs parent Technical Committee The %rchitecture ;oard revie#s

the recommended Submission for .D% compliance and technical merit nce the

%; has endorsed it, members of the relevant TC vote on the recommended

Submission by email Successful completion of this vote moves the

recommendation to .3Hs ;oard of Directors (;oD)

3.2.7 Business Committee Questionnaire

;efore the ;oD ma"es its final decision on turning a Technical Committee

recommendation into an .3 published specification, it as"s its ;usiness

Committee to evaluate #hether implementations of the specification #ill be

publicly available To do this, the ;usiness Committee #ill send a uestionnaire

9;C: to every .3 .ember listed as a Submitter on the recommended

Submission .embers that are not Submitters can also complete a ;usiness

Committee uestionnaire for the Submission if they choose

7f no organi1ation commits to ma"e use of the specification, then the ;oD #ill

typically not act on the recommendation to adopt it > so it is very important that

submitters respond to the ;C

nce the ;usiness Committee has received satisfactory ;C responses, the

;oard ta"es the final publication vote % Submission that has been adopted by the

;oard is termed an lpha Specification

%t this point the &* process is complete

3.2.8 Finalization & Revision

%ny specification adopted by .3 by any mechanism, #hether &* or

other#ise, is subect to &inalisation % &inali1ation Tas" &orce (&T&) is chartered

by the TC that recommended the Specification its tas" is to correct any problems

reported by early users of the published specification The &T& first collaborates

#ith .3Hs Technical 4ditor to prepare a cleaned-up version of the %lpha

Specification #ith submission-specific material removed This is the ;eta


8/19/2019 sysa-13-03-20 (1)

9/36


specification, and is made publicly available via .3Hs #eb site The &T& then

#or"s through the list of bug reports (KissuesK) reported by users of the ;eta

specification, to produce a &inalisation eport and another ;eta specification

(usually ;eta/), #hich is a candidate for &ormal publication nce endorsed by

the %; and adopted by the relevant TC and ;oD, this is published as the final,

&ormal Specification

8ong-term maintenance of .3 specifications is handled by a se$uence of

evision Tas" &orces (T&s), each one chartered to rectify any residual problems

in the most-recently published specification version &or full details, see *F*

section @@ 9*F*:

4 Instructions for Submitters

4.1OMG MembershipTo submit to an &* issued by the *latform Technology Committee an

organisation shall maintain either *latform or Contributing .3 .embership

from the date of the initial submission deadline, #hile to submit to a Domain &*

an organisation shall maintain either a Contributing or Domain membership

4.2Intellectual Property Rights

;y ma"ing a Submission, an organisation is deemed to have granted to .3 a

perpetual, none'clusive, irrevocable, royalty-free, paid up, #orld#ide license to

copy and distribute the document and to modify the document and distribute

copies of the modified version, and to allo# others to do the same Submitter(s)

shall be the copyright o#ners of the te't they submit, or have sufficient copyright

and patent rights from the copyright o#ners to ma"e the Submission under the

terms of .3Hs 7* *olicy 4ach Submitter shall disclose the identities of all

copyright o#ners in its Submission

4ach .3 .ember that ma"es a #ritten Submission in response to this &*

shall identify patents containing 4ssential Claims that it believes #ill be infringed

if that Submission is included in an .3 &ormal Specification and implemented

;y ma"ing a #ritten Submission to this &*, an .3 .ember also agrees tocomply #ith the *atent 8icensing terms set out in section 2I

This section @/ is neither a complete nor an authoritative statement of a

submitterHs 7* obligations > see 97*: for the governing document for all

.3Hs 7* policies


8/19/2019 sysa-13-03-20 (1)

10/36


4.3Submission Effort

%n &* submission may re$uire significant effort in terms of document

preparation, presentations to the issuing T&, and participation in the T&

evaluation process .3 is unable to reimburse submitters for any costs in

conunction #ith their submissions to this &*

4.4Letter of Intent

4very organisation intending to ma"e a Submission against this &* shall submit

a 8etter of 7ntent (87) signed by an officer on or before the deadline listed in

section 2, or as later varied by the issuing Tas" &orce

The 87 should designate a single contact point #ithin the submitting

organi1ation for receipt of all subse$uent information regarding this &* and the

submission The name of this contact #ill be made available to all .3

members 87s shall be sent by email, fa' or paper mail to the “&* SubmissionsDes"” at the .3 address sho#n on the first page of this &*

% suggested template for the 8etter of 7ntent is available at http+BBdocomgorgBloi

987:

4.5Business Committee terms

This section contains the te't of the ;usiness Committee &* attachment

concerning commercial availability re$uirements placed on submissions This

attachment is available separately as .3 document omgB/-/-I0

4.5.1 Introduction

.3 #ishes to encourage rapid commercial adoption of the specifications it

publishes To this end, there must be neither technical, legal nor commercial

obstacles to their implementation &reedom from the first is largely udged

through technical revie# by the relevant .3 Technology Committees the

second t#o are the responsibility of the .3 ;usiness Committee The ;C also

loo"s for evidence of a commitment by a submitter to the commercial success of

products based on the submission

4.5.2 Business Committee evaluation criteria

-...0 1iable to implement acro"" platform"

Jhile it is understood that final candidate .3 submissions often combine

technologies before they have all been implemented in one system, the ;usiness

Committee nevertheless #ishes to see evidence that each maor feature has been


8/19/2019 sysa-13-03-20 (1)

11/36


implemented, preferably more than once, and by separate organisations *re-

product implementations are acceptable Since use of .3 specifications should

not be dependent on any one platform, cross-platform availability and

interoperability of implementations should be also be demonstrated

-... 2ommercial a#ailability

7n addition to demonstrating the e'istence of implementations of the

specification, the submitter must also sho# that products based on the

specification are commercially available, or #ill be #ithin / months of the date

#hen the specification #as recommended for adoption by the appropriate Tas"

&orce *roof of intent to ship product #ithin / months might include+

• % public product announcement #ith a shipping date #ithin the time limit

• Demonstration of a prototype implementation and accompanying draft

user documentation

%lternatively, and at the ;usiness CommitteeHs discretion, submissions may be

adopted #here the submitter is not a commercial soft#are provider, and therefore

#ill not ma"e implementations commercially available Go#ever, in this case the

;C #ill re$uire concrete evidence of t#o or more independent implementations

of the specification being used by end-user organisations as part of their

businesses

egardless of #hich re$uirement is in use, the submitter must inform the .3 of

completion of the implementations #hen commercially available

-...3 cce"" to Intellect!al Property +ight"

.3 #ill not adopt a specification if .3 is a#are of any submitter, member or

third party #hich holds a patent, copyright or other intellectual property right

(collectively referred to in this policy statement as K7*K) #hich might be

infringed by implementation or recommendation of such specification, unless

.3 believes that such 7* o#ner #ill grant an appropriate license to

organi1ations (#hether .3 members or not) #hich #ish to ma"e use of the

specification 7t is the goal of the .3 to ma"e all of its technology available

#ith as fe# impediments and disincentives to adoption as possible, and therefore

.3 strongly encourages the submission of technology as to #hich royalty-free

licenses #ill be available

The governing document for all intellectual property rights (“7*”) policies of

bect .anagement 3roup is the 7ntellectual *roperty ights statement,

available at+ http+BBdocomgorgBipr 7t should be consulted for the authoritative

statement of the submitterHs patent disclosure and licensing obligations


8/19/2019 sysa-13-03-20 (1)

12/36


-...- P!blication of the "pecification

Should the submission be adopted, the submitter must grant .3 (and its

sublicensees) a #orld#ide, royalty-free licence to edit, store, duplicate and

distribute both the specification and #or"s derived from it (such as revisions and

teaching materials) This re$uirement applies only to the #ritten specification, notto any implementation of it *lease consult the 7ntellectual *roperty ights

statement (http+BBdocomgorgBipr) for the authoritative statement of the

submitterHs copyright licensing obligations

-... 2ontin!ing "!pport

The submitter must sho# a commitment to continue supporting the technology

underlying the specification after .3 adoption, for instance by sho#ing the ;C

development plans for future revisions, enhancement or maintenance

4.6Responding to RFP items

4.6.1 Complete proposals

Submissions should propose full specifications for all of the relevant re$uirements

detailed in Section 2 of this &* Submissions that do not present complete

proposals may be at a disadvantage

Submitters are encouraged to include any non-mandatory features listed in

Section 2

4.6.2 Additional specifications

Submissions may include additional specifications for items not covered by the

&* and #hich they believe to be necessary 7nformation on these additional

items should be clearly distinguished Submitters shall give a detailed rationale for

#hy any such additional specifications should also be considered for adoption

Submitters should note that a T& is unli"ely to consider additional items that are

already on the roadmap of an .3 T&, since this #ould pre-empt the normal

adoption process

4.6.3 Alternative approaches

Submitters may provide alternative &* item definitions, categori1ations, and

groupings so long as the rationale for doing so is clearly stated 4$ually,

submitters may provide alternative models for ho# items are provided if there are

compelling technological reasons for a different approach


8/19/2019 sysa-13-03-20 (1)

13/36


4.7Confidential and Proprietary Information

The .3 specification adoption process is an open process esponses to this

&* become public documents of the .3 and are available to members and

non-members ali"e for perusal

8/19/2019 sysa-13-03-20 (1)

14/36


97S/: These 7S terms are compatible #ith the same terms in 74T& &C

/5 9&C/5: Go#ever, the &C /5 terms "must", "must not",

"optional", "required", "recommended" and "not recommended" shall

not be used (even though they are permitted under &C/5)

4.9.2 Mandatory Outline

All submissions shall use the follo#ing structure, based on the .3

Specification template 9T4.*8:+

Section I of the submission shall be used to provide all non-normative supporting

material relevant to the evaluation of the proposed specification, including+

- The full name of the submission

- % complete list of all .3 .ember(s) ma"ing the submission, #ith a

named contact individual for each

- The acronym proposed for the specification (eg !.8, C;%)

- The name and .3 document number of the &* to #hich this is a

response

- The .3 document number of the main submission document

- vervie# or guide to the material in the submission

- Statement of proof of concept (see @6)

- 7f the proposal does not satisfy any of the general re$uirements stated in

Section A, a detailed rationale e'plaining #hy

- Discussion of each of the “7ssues To ;e Discussed” identified in Section

2

- %n e'planation of ho# the proposal satisfies the specific re$uirements

and (if applicable) re$uests stated in Section 2

Section and subse$uent sections of the submission shall contain the normative

specification that the Submitter(s) isBare proposing for adoption by .3,

including+

• Scope of the proposed specification

• verall design rationale


8/19/2019 sysa-13-03-20 (1)

15/36


• Conformance criteria for implementations of the proposed specification,

clearly stating the features that all conformant implementations shall support,

and any features that implementations may support, but #hich are not

mandatory

• % list of the normative references that are used by the proposedspecification

• % list of terms that are used in the proposed specification, #ith their

definitions

• % list of any special symbols that are used in the proposed specification,

together #ith their significance

• The proposed specification itself

Section I #ill be deleted from any specification that .3 adopts and publishes

Therefore Section I of the submission shall contain no normative material, and

any non-normative material outside section I shall be e'plicitly identified

The main submission document and any models or other machine-interpretable

files accompanying it shall be listed in an inventory file conforming to the

inventory template 97

8/19/2019 sysa-13-03-20 (1)

16/36


Submission deadlines %cceptable formats are %dobe &rame.a"er source,

7SB74C /20II+/II2 (penDoc ), %S7S Doc;oo" @' (or later) and

7SB74C /5AII+/II6 (=.8, doc')

Submitters should ensure that they receive confirmation of receipt of their

submission

5 General Requirements on Proposals

5.1Requirements

5.1.1 Use of modelling languages

Submitters are encouraged to e'press models using .3 modelling languages

such as !.8, .&, CJ. and S*4. (subect to any further constraints on the

types of the models and modeling technologies specified in Section 2 of this&*) Submissions containing models e'pressed using .3 modeling languages

shall be accompanied by an .3 =.7 9=.7: representation of the models

(including a machine-readable copy) % best effort should be made to provide an

.3 =.7 representation even in those cases #here models are e'pressed via

non-.3 modeling languages

5.1.2 PIMs & PSMs

Section 2 of this &* specifies #hether *7.(s), *S.(s), or both are being

solicited 7f proposals specify a *7. and corresponding *S.(s), then the rules

specifying the mapping(s) bet#een the *7. and *S.(s) shall either be identified by reference to a standard mapping or specified in the proposal 7n order to allo#

possible inconsistencies in a proposal to be resolved later, proposals shall identify

#hether itHs the mapping techni$ue or the resulting *S.(s) that shall be

considered normative

5.1.3 Complete submissions

*roposals shall be precise and functionally complete %ny relevant assumptions

and conte't necessary to implement the specification shall be provided

5.1.4 Reuse*roposals shall re!"e e'isting .3 and other standard specifications in

preference to defining ne# models to specify similar functionality

5.1.5 Changes to existing specifications


8/19/2019 sysa-13-03-20 (1)

17/36


4ach proposal shall ustify and fully specify any change" or e4ten"ion" to e'isting

.3 specifications necessitated by adopting that proposal 7n general, .3

favors proposals that are !pward" compatible #ith e'isting standards and that

minimi1e changes and e'tensions to e'isting specifications

5.1.6 Minimalism

*roposals shall factor out functionality that could be used in different conte'ts

and specify their models, interfaces, etc separately Such minimali"m fosters re-

use and avoids functional duplication

5.1.7 Independence

*roposals shall use or depend on other specifications only #here it is actually

necessary Jhile re-use of e'isting specifications to avoid duplication #ill be

encouraged, proposals should avoid gratuitous use

5.1.8 Compatibility

*roposals shall be compatible #ith and !"able #ith e'isting specifications from

.3 and other standards bodies, as appropriate Separate specifications offering

distinct functionality should be usable together #here it ma"es sense to do so

5.1.9 Implementation flexibility

*roposals shall preserve ma'imum implementation fle4ibility 7mplementation

descriptions should not be included and proposals shall not constrain

implementations any more than is necessary to promote interoperability

5.1.10Encapsulation

*roposals shall allo# independent implementation" that are "!b"tit!table and

interoperable %n implementation should be replaceable by an alternative

implementation #ithout re$uiring changes to any client

5.1.11Security

7n order to demonstrate that the specification proposed in response to this &*

can be made secure in environments that re$uire security, ans#ers to the

follo#ing $uestions shall be provided+

• Jhat, if any, security-sensitive elements are introduced by the proposalM

• Jhich accesses to security-sensitive elements should be subect to

security policy controlM

• Does the proposed service or facility need to be security a#areM


8/19/2019 sysa-13-03-20 (1)

18/36


• Jhat default policies (eg, for authentication, audit, authori1ation, message

protection etc) should be applied to the security sensitive elements

introduced by the proposalM f #hat security considerations should the

implementers of your proposal be a#areM

The .3 has adopted several specifications, #hich cover different aspects ofsecurity and provide useful resources in formulating responses 9S4C: 9%D:

5.1.12Internationalization

*roposals shall specify the degree of internationali1ation support that they

provide The degrees of support are as follo#s+

a) !ncategori1ed+ 7nternationali1ation has not been considered

b) Specific to Nregion nameO+ The proposal supports the customs of the

specified region only, and is not guaranteed to support the customs of any

other region %ny fault or error caused by re$uesting the services outside of a

conte't in #hich the customs of the specified region are being consistently

follo#ed is the responsibility of the re$uester

c) Specific to Nmultiple region namesO+ The proposal supports the customs of

the specified regions only, and is not guaranteed to support the customs of any

other regions %ny fault or error caused by re$uesting the services outside of a

conte't in #hich the customs of at least one of the specified regions are being

consistently follo#ed is the responsibility of the re$uester

d) 4'plicitly not specific to Nregion(s) nameO+ The proposal does not support

the customs of the specified region(s) %ny fault or error caused by re$uestingthe services in a conte't in #hich the customs of the specified region(s) are

being follo#ed is the responsibility of the re$uester

5.2Evaluation criteria

%lthough the .3 adopts model-based specifications and not implementations

of those specifications, the technical viability of implementations #ill be ta"en

into account during the evaluation process The follo#ing criteria #ill be used+

5.2.1 Performance

*otential implementation trade-offs for performance #ill be considered

5.2.2 Portability

The ease of implementation on a variety of systems and soft#are platforms #ill

be considered


8/19/2019 sysa-13-03-20 (1)

19/36


5.2.3 Securability

The ans#er to $uestions in section A shall be ta"en into consideration to

ascertain that an implementation of the proposal is securable in an environment

re$uiring security

5.2.4 Conformance: Inspectability and Testability

The ade$uacy of proposed specifications for the purposes of conformance

inspection and testing #ill be considered Specifications should provide sufficient

constraints on interfaces and implementation characteristics to ensure that

conformance can be unambiguously assessed through both manual inspection and

automated testing

5.2.5 Standardized Metadata

Jhere proposals incorporate metadata specifications, .3 standard =.7

metadata 9=.7: representations should be provided

6 Specific Requirements on Proposals

6.1Problem Statement

6.1.1 Context

The term “Safety-Sensitive Consumer device” (SSCD) refers to a category of

industrial products used by consumer users, including automobiles, servicerobots, medical devices and clinical systems, and smart houses *reventing

failures of the embedded soft#are in SSCDs is going to be vital for consumer

safety !nli"e traditional industrial machinery, such consumer devices must be

dependable in diverse, open and dynamic environments #here the need for safety,

reliability and even availability of such devices is no longer an option but a

re$uirement 9D4S: Table 1 provides a comparison between

various aspects of factory machines and SSCDs.

Table 1 : Comparison on Factory Machines and Safety-Sensitive Consumer evices

&actory .achines Safety-Sensitive Consumer Devices


8/19/2019 sysa-13-03-20 (1)

20/36


8/19/2019 sysa-13-03-20 (1)

21/36


6.1.2 Motivation

The follo#ing three concepts can help enhance the development capability for

SSCDs These concepts could apply individually and in some cases collectively

The first concept is the process of developing a dependable system

Dependability %ssurance should ta"e into consideration various activities of the

development process &or e'ample, rapid iteration of development can reduce

“time-to-mar"et” for a SSCD Considering the diversity of users? environments,

the only #ay to ensure the features of SSCDs is to rapidly and repeatedly validate

the control soft#are to cover all use cases as much as possible %n %ssurance

Case should provide guidance about the organi1ation of these iterations, and in

particular, to the validation and verification activities performed at each iteration

The second concept is “*roven in !se” 9*L4

8/19/2019 sysa-13-03-20 (1)

22/36


6.1.3 The Need for a Standard

% standardised Dependability %ssurance &rame#or" for SSCDs #ill enable

interoperable tools, help establish industry-#ide norms for best practices,

promote common methodologies and reduce the costs of producing safer

consumer devices

Dependability %ssurance is, in general, an e'tension of system engineering

processes ho#ever, the standardi1ed Dependability %ssurance &rame#or"

should not restrict organi1ations in their selection of system engineering

methodology, modeling languages or tools 7nstead, it should provide fle'ible

interfaces that fit into many different system engineering conte'ts

6.2Scope of Proposals Sought

This &* see"s proposals that specify ho# to assure the dependability of

consumer devices 7n particular this &* solicits a specification for building ustifiably-dependable SSCDs that includes+

ne or more Dependability Conceptual .odels (DC.s) defining the factors

of dependability,

/ ne or more templates to be used to construct Dependability %ssurance

Cases (D%Cs) for SSCDs, and

0 ne or more Dependability *rocess .odels (D*.s) that define rapid and

iterative processes for engineering dependable SSCDs


8/19/2019 sysa-13-03-20 (1)

23/36


Systems engineering processes and assurance processes both include specificactivities aimed at building dependable systems The D%& shall include one or

more D*.s, and the submitted D%C shall refer to process activities in order to

ustify dependability

The D%C template(s) shall utili1e the D%C vie# illustrated in figure , and shall

refer to the process vie# describing the SSCD engineering process

&igure / provides an e'ample of a D*. in #hich embedded control soft#are is

developed and dependability cases are simultaneously generated


&igure elationship bet#een vie#s

8/19/2019 sysa-13-03-20 (1)

24/36


&igure / %n e'ample of a D*.

6.3Relationship to OMG specifications

6.3.1 Relationship to OMG MARTE

The Dependability %ssurance &rame#or" may refer to

8/19/2019 sysa-13-03-20 (1)

25/36


6.3.4 Relationship to OMG XMI

.3 =.7 (formalB/I-I6-I5) provides seriali1ation and interoperability rules

.& metamodels

6.3.5 Relationship to OMG SysML, SPEM, BPMN.3 Sys.8 (formalB/I/-I2-I), ;*.< (formalB/I-I-I0), S*4.

(formalB/II6-I@-I) are related to modelling systems and processes S*4. and

;*.< should be considered for modelling D*.

6.3.6 Relationship to OMG ODM

.3 D. (formalB/II5-IA-I) is related to modelling concepts These

specifications should be considered for modelling vocabularies for DC.

6.4Related non-OMG Activities, Documents and Standards

6.4.1 GSN Community Standard

3S< is the graphical notation for assurance cases defined by 3S< community

standard version I, /I 3S< is already aligned #ith S%C.

6.4.2 ISO 26262

7S /2/2/ is the international standard to cover the &unctional Safety aspects for automobiles 7t provides guidance on automotive safety lifecycle activities

*roposals should e'tend the scope of 7S /2/2/, #hich only addresses electrical

and electronic (4B4) system issues Ta"ing “engine stall” as an e'ample, this is

categori1ed as a safety issue in automotive companies, #ho must ensure it does

not happen at the time of vehicle running, #hile it is regarded as a $uality issue in

7S/2/2/ ;y enhancing 7S/2/2/ #ith D%&, proposals may address safety

issues that are not covered by 7S/2/2/

6.4.3 IEC 61508

74C 2AI6 is the international standard to cover the &unctional Safety aspects for

all "ind of industry 7S/2/2/ is an application of 74C2AI6 for automotive 4B4

systems, #hile 4

8/19/2019 sysa-13-03-20 (1)

26/36


6.4.4 ISO15026

7SAI/2 is the international standard for system and soft#are assurance, #hich

provides us #ith a generic frame#or" for the assurance cases and lin"s to life

cycle processes

The proposal of this &* should not be inconsistent #ith the mandatory

re$uirements of 7SB74C AI/2

6.4.5 ISO/IEC 62741

7SB74C 2/Q@ is the international standard for the dependability case 7t

provides a generic frame#or" for the dependability argumentation

The proposal of this &* should not be inconsistent #ith the mandatory

re$uirements of 7SB74C 2/Q@

6.4.6 ISO/FDIS 13482

7SB&D7S 0@6/ is the final draft of an international standard to specify the

safety re$uirements for personal robots

This proposal #ould not provide specific safety re$uirements re$uired in

7SB&D7S 0@6/, but can provide a general argument structure to assure the

safety, as a part of dependability of consumer devices

6.4.7 TCG standards

The Trusted Computing 3roup (TC3) is an 7T security standards group that

develops, defines and promotes open, vendor-neutral, global industry standards

supportive of a hard#are-based root of trust, for interoperable trusted computing

platforms

The TC3 standards cover 7T-related security matters only, #hile this proposal

#ould loo" to dependability

6.4.8 DEOS Whitepaper

This paper, #ritten by the EST C4ST Dependable 4mbedded perating System

*roect, describes a Eapanese national proect called D4S, #hich aims to

develop dependable embedded systems

6.4.9 DA Draft Guidance on Infusion Pumps

The D% Draft 3uidance on Total *roduct 8ife Cycle+ 7nfusion *umps -

*remar"et

8/19/2019 sysa-13-03-20 (1)

27/36


6.4.10ISO 14971

7S @5Q is an 7S standard that represents the re$uirements for a ris"

management system for medical devices The most recent revision #as published

in /IIQ

6.4.11FDA Quality System Regulation, 21 CFR Part 820, Design Controls

&D% / C& *art 6/I, also "no#n as the uality System egulation S

outlines Current 3ood .anufacturing *ractice C3.* regulations that govern

the methods used in, and the facilities and controls used for, the design,

manufacture, pac"aging, labeling, storage, installation, and servicing of all

finished devices intended for human use

6.4.12IEC 60601-1

74C 2I2I is a series of technical standards for the safety and effectiveness of

medical electrical e$uipment, published by the 7nternational 4lectrotechnicalCommission &irst published in 5QQ and regularly updated and restructured, as

of /I it consists of a general standard, about I collateral standards, and about

2I particular standards 74C 2I2I- covers .edical electrical e$uipment

re$uirements for basic safety and essential performance

6.4.13 ASTM F2761

This standard specifies general re$uirements, a model and frame#or" for

integrating e$uipment to create an 7ntegrated Clinical 4nvironment (7C4) 7t

specifies the characteristics necessary for the safe integration of .edical Devices

and other e$uipment, via an electronic interface, from different .anufacturers

into a single medical system for the care of a single high acuity *atient

6.5Mandatory Requirements

The proposal shall define one or more Dependability Conceptual .odels (DC.s)

4ach DC. shall identify dependability elements and define the relationships among them

The proposal shall define Dependability %ssurance Case (D%C) template(s)

The D%C template(s) shall comply #ith S%C.

4ach D%C template shall refer to one or more DC.(s)

The proposal shall define Dependability *rocess .odel(s) (D*.s)

4ach D%C template shall refer to one or more D*.(s)

The D*.(s) shall be capable of describing rapid development processes, iterative

development processes and differential development processes


8/19/2019 sysa-13-03-20 (1)

28/36


The D*.(s) shall be capable of describing rapid dependability assurance processes,

iterative dependability assurance processes and differential dependability

assurance processes

The proposal shall define terminology related to D%C, DC. and D*. in the conte't of

SSCDs

The DC.(s) and D*.(s) shall be defined using a suitable .&-based language, in order

to assure that instances of these models may be serialised using =.7

The submitted D*.s and D%Cs shall be customi1able for specific SSCDs, and lin"ed to

the system architecture of those SSCDs

The D%C template(s) shall define reusable argument structures for assuring the

dependability of SSCDs, and shall specify ho# the dependability claims of the

D%Cs are achieved, rationali1ed and proved

The D%C template(s) shall be capable of incorporating “*roven 7n !se” evidence

The D%C template(s) shall be customi1able by adding system-specific arguments that refer to specific system engineering vie#s

Customi1ation of the D%C template(s) shall be supported by custom process vie#s that

are based on process models, and also refer to specific system engineering vie#s

6.6Non-mandatory features

The DC. may utili1e standards applicable for the dependability of SSCDs

The D%& may include "ey elements related to system engineering processes

The D%& may define various relationships bet#een process vie#s, assurance vie#s and

property vie#s so that assurance cases can be structured according to andreference process activities and property elements

The D%& may e'tend any e'isting system engineering modeling language in order to

provide an assurance vie#point, such as Sys.8, %%D8, 4%ST-%D8, %rchi.ate,

.%T4 and Simulin"

The D%& may e'tend any e'isting system engineering language in order to provide a

process vie#point

The D%& may e'tend any e'isting system engineering language in order to provide a

vie#point describing conceptual models for system properties

The D%& may define the relationships bet#een system engineering vie#point and processvie#point, to allo# assurance cases to be structured according to, and reference,

system architecture and process activities

The D%& may define the relationships bet#een assurance vie#point and property

vie#point, to allo# assurance cases to be structured according to, and reference,

property elements


8/19/2019 sysa-13-03-20 (1)

29/36


The D%C template(s) may reference system engineering elements of the D%& #here

appropriate

The D%C template(s) may re$uire additional S%C. features, in support of modular

arguments

6.7Issues to be discussed

These issues #ill be considered during submission evaluation They should not be

part of the proposed normative specification *lace your responses to these

7ssues in Section I of your submission

• Simplicity in representation, instantiation and implementation of the

DC.(s) and the D%C template(s)

• Compatibility #ith other .3 and

8/19/2019 sysa-13-03-20 (1)

30/36


etter of Intent (%I) deadline 0"t 6!ne 703

Initial S!bmi""ion deadline 00th 8o#ember 703

1oter regi"tration clo"e" th 8o#ember 703

Initial S!bmi""ion pre"entation" 5ee of 9th $ecember 703

+e#i"ed S!bmi""ion deadline 09th May 70-

+e#i"ed S!bmi""ion pre"entation" 5ee of 0th 6!ne 70-

Appendix A References & Glossary Specific to this

RFP

A.1 References Specific to this RFPThe follo#ing documents are referenced in this document+

74C 2I0II-+/II0 Dependability management

7nternational 4lectrotechnical Commission, 3eneva, S#it1erland

7S /2/2/+/I oad vehicles > &unctional safety

7nternational rgani1ation for Standardi1ation, 3eneva, S#it1erland

4ngineering for system assurance

8/19/2019 sysa-13-03-20 (1)

31/36


;ritish Standard eliability of systems, e$uipment and components, /II

;ritish Standards 7nstitute

9S%4/I: apid ;oundary Detection for .odel ;ased Diesel 4ngine

Calibration

Soshida/I S%4 Jorld Congress, .ay /I

9S%C.: Structured %ssurance Case .etamodel

http://www.omg.org/"pec/S2M

9%L7P74

8/19/2019 sysa-13-03-20 (1)

32/36


Moel Base Develo!ment (MBD) – an approach to developing embedded

control soft#are in #hich models of soft#are behavior serve as e'ecutable

specifications, artefacts for analysis, test scenarios, and sometimes the basis for

automatic generation of source codes

Appendix B General Reference and Glossary

B.1 General References

The follo#ing documents are referenced in this document+

9;C: .3 ;oard of Directors ;usiness Committee uestionnaire,

http://doc.omg.org/bc

9CC.: C;% Core Components Specification

http://www.omg.org/"pec/22M/"y"a;03;73;03;new;template.doc

9C;%: Common bect e$uest ;ro"er %rchitecture (C;%)

http://www.omg.org/"pec/2%+A/

9C*: !.8 *rofile for C;%,

http://www.omg.org/"pec/2%+P

9CJ.: Common Jarehouse .etamodel Specification

http://www.omg.org/"pec/25M

94DC: !.8 *rofile for 4DC Specificationhttp://www.omg.org/"pec/

8/19/2019 sysa-13-03-20 (1)

33/36


987: .3 &* 8etter of 7ntent template

http://doc.omg.org/loi

9.D%a: .3 %rchitecture ;oard, K.odel Driven %rchitecture - %

Technical *erspectiveD

http://www.omg.org/mda/paper".htm

9.D%b: Developing in .3Hs .odel Driven %rchitecture (.D%)

http://www.omg.org/mda/paper".htm

9.D%c: .D% 3uide

http://www.omg.org/doc"/omg/73;7;70.pdf

9.D%d: .D% KThe %rchitecture of Choice for a Changing Jorld

http://www.omg.org/mda

9.&: .eta bect &acility Specification

http://www.omg.org/"pec/M%E/

9 ules for the structure and drafting of

7nternational Standards

http://i"otc.i"o.org/li#elin/li#elin>f!nc?llBobCId?-37-

9.-D*:

7SB74C IQ@2

9S4C: C;% Security Service

http://www.omg.org/"pec/S

8/19/2019 sysa-13-03-20 (1)

34/36


9TS: Trading bect Service

hptp://www.omg.org/"pec/'+$

8/19/2019 sysa-13-03-20 (1)

35/36


Meta #b$ect *acility (M#*) - %n .3 standard, closely related to !.8, that

enables metadata management and language definition

Moel - % formal specification of the function, structure andBor behavior of an

application or system

Moel Driven Arc"itecture (MDA) - %n approach to 7T system specification that

separates the specification of functionality from the specification of the

implementation of that functionality on a specific technology platform

+ormative > *rovisions to #hich an implementation shall conform to in order to

claim compliance #ith the standard (as opposed to non-normative or informative

material, included only to assist in understanding the standard)

+ormative %eference > eferences to documents that contain provisions to

#hich an implementation shall conform to in order to claim compliance #ith the

standard

Platform - % set of subsystemsBtechnologies that provide a coherent set of

functionality through interfaces and specified usage patterns that any subsystem

that depends on the platform can use #ithout concern for the details of ho# the

functionality provided by the platform is implemented

Platform ne!enent Moel (PM) - % model of a subsystem that contains no

information specific to the platform, or the technology that is used to reali1e it

Platform S!ecific Moel (PSM ) - % model of a subsystem that includes

information about the specific technology that is used in the reali1ation of it on a

specific platform, and hence possibly contains elements that are specific to the

platform

%e&uest for nformation (%*) - % general re$uest to industry, academia, and

any other interested parties to submit information about a particular technology

area to one of the .3Hs Technology Committee subgroups

%e&uest for Pro!osal (%*P) - % document re$uesting .3 members to submit

proposals to an .3 Technology Committee

,ask *orce (,*) - The .3 Technology Committee subgroup responsible for

issuing a &* and evaluating submission(s)

,ec"nology Committee (,C) - The body responsible for recommending

technologies for adoption to the ;oD There are t#o TCs in .3 > the

Platform '2 (*TC) focuses on 7T and modeling infrastructure related standards

#hile the $omain '2 (DTC) focuses on domain specific standards


8/19/2019 sysa-13-03-20 (1)

36/36


nifie Moeling anguage (M) - %n .3 standard language for

specifying the structure and behavior of systems The standard defines an

abstract synta' and a graphical concrete synta'

M Profile - % standardi1ed set of e'tensions and constraints that tailors !.8

to particular use

.M Metaata nterc"ange (.M) - %n .3 standard that facilitates

interchange of models via =.8 documents

sysa-13-03-20 (1)

Documents

Transcript of sysa-13-03-20 (1)