In the figure 9-2 (DPM), there is a confusing arrow from "Dependability Argument Construction" to "Dependability Requirements Definition" specified. The arrow should be from "Dependability Argument Construction" to the diamond (judgement block" in the top left corner of the figure so that the arrow can be connected to "Dependability Analysis".

The arrow is to be removed

The arrow is going to be removed because the arrow is misleading as if the "Dependability Requirements Definition" process requires an input from the "Dependability Argumentation Construction" process which is a downstream process of the "Dependability Requirements Definition".

There are some misspelled words in the generated XMI, which concerns me. This would imply that the XMI is not automatically generated from the model, which will cause maintenance problems. For example:
Figure 8 9 - Modification Argument Part of the DAC template for Evolutionary Development Argument Structure "ModificationArgument" was misspelled.
The XMI should be generated from the model to ensure a correct and consistent specification.

Fix the misspell

The misspells are to be fixed as follows and the xmi file with correction is attached below together with the old xmi file for comparison.

・Static Dependability Analysis Argument

sufficently
->
sufficiently

・ProvenInUseArgument

condintion
->
condition

・Modification Argument

condintion
->
condition

・DependabilityAllocationArgument

arctecture
->
architecture

adeaute
->
adequate

On the vast majority of the diagrams, the associations are not named. This is not normally a problem but is in this specification. This is because the associations are referenced in the text. For example:

Figure 7 13 - Assessment package
Associations
conform:Confirmation Review [1]
checks whether Artifact satisfies the Assurance Requirement.
refer:Confirmation Review [1]
specifies the reference of Assurance Requirement by Confirmation Review.

Since the associations are listed without names on the diagrams, it is difficult to determine which are which.

The association names are to be added

The original issue raised by Mathew under "for example..." has been already fixed in the beta 1 and no longer a problem.

The association names are added in the figure 7-13 which is attached in the DAF-9.

The term "exceptional treatment" is used several times in the specification. I am not sure what it means. Possibly you mean "optional step" or "additional activity" or some other combination of words.
.

Proposal to remove the phrase

The following sentense is going to be removed from the specification as the sentence is over specified and exaggerated. Likewise, all the sentences with "exceptional treatment" (4 places) are going to be removed for the same reason.

9.3.2 : When the existing System Requirements Definition has been found as insufficient in the course of the System Architecture Design, it is possible to rework the System Requirements Definition as an exceptional treatment.

9.3.3 : When the existing System Architecture Design has been found as insufficient in the course of Hardware Development, it is possible to rework the System Architecture Design as an exceptional treatment.

9.3.5 : When the Hardware Development results and/or the Software Development results have been found as insufficient in the course of Verification and Validation, it is possible to rework the Hardware Development and/or the Software Development as an exceptional treatment. Major rework may be treated as an issue that should be treated in the next development loop.

9.4.2 : When the Difference Analysis result has been found as insufficient in the course of the Impact Analysis, it is possible to rework the Difference Analysis as an exceptional treatment.

The BPMN diagrams do not show the inputs and outputs for the activities in section 9. For example, the diagram in section 9.2.1 lists all inputs and outputs as artifacts even though there are several.
"The inputs of this activity are

• Product Plan provided by upper level processes including Planning,
• Incident Reports from the Problem flow, and
• Development results from the Evolutionary Development Process consisting of the Difference Analysis activity and the Impact Analysis activity."
  Is there any way to show these (and all other) inputs and outputs on the process diagrams? It would help make them standalone. Artifacts seems to be very little to go on.

Inputs

Those inputs specified in the spec are just examples and we do not think they should be included in the BPMN diagrams. We will explain those are examples in the main text instead as follows. Likewise, all the descriptions related to inputs and outputs are going to be modified accordingly.

OLD :
The inputs of this activity are

• Product Plan provided by upper level processes including Planning,
• Incident Reports from the Problem flow, and
• Development results from the Evolutionary Development Process consisting of the Difference Analysis activity and the Impact Analysis activity.

NEW :
As examples of inputs, they are the following documents;

• Product Plan provided by upper level processes including Planning,
• Incident Reports from the Problem flow, and
• Development results from the Evolutionary Development Process consisting of the Difference Analysis activity and the Impact Analysis activity.

9.3.4.7 Software Calibration & Verification & Validation
"Various frameworks to standardize and generalize software and to use them in various products universally are developed in order to reduce control software development cost and to improve efficiency of the process. Calibration is a process to tune parameters implemented in software according to the specific product requirements and target market environment. It is based on the possibility of using the same software for various products with varying parameters."
This is more an activity of developing software product lines rather than calibration V&V. It is normally done post-production over the course of several projects and not here as restructuring can change the size, performance, reliability, etc. It can also be done prior to starting the development to try to identify reusable features. At this stage, it is far too late.

Propose to remove sentences

The following sentences are going to be removed as suggested, as the description contains some post-development activities.

Sentences to be removed;
"Various frameworks to standardize and generalize software and to use them in various products universally are developed in order to reduce control software development cost and to improve efficiency of the process. Calibration is a process to tune parameters implemented in software according to the specific product requirements and target market environment. It is based on the possibility of using the same software for various products with varying parameters."

9.3.4.5 Simplification Optimization
"Therefore investigation to achieve equivalent quality control by simplified and/or optimized approach considering constraints of implementation size, cost and so on."
Please rephrase for clarity.

Proposal to rephrase the sentence

OLD : Therefore investigation to achieve equivalent quality control by simplified and/or optimized approach considering constraints of implementation size, cost and so on.

New : Therefore, an implementation to achieve equivalent quality of the control model is deployed with simplified and/or optimized approach for codes, considering constraints of implementation size and cost.

"In this clause we use the terminology of Control Software Development process instead of Control Software Development activity, and also use the terminology of activity instead of task and the terminology of task instead of sub-task, for simplicity."
Why change the terminology? It would be better to use the same terminology throughout the document and consistent with BPMN, since that is what is being used.

Activity in SPEM is picked instead of Task in BPMN

The following sentence is going to be added in the Section 7.3.2.

In this document, the term Activity is used according to SPEM2.0, instead of the term Task to BPMN as the conceptioal model of process follows SPEM2.0.

In sysa/14-11-01, section 8.3 (Dependability Allocation Argument), the example is very dense and poorly-formatted. Please re-phrase & re-format to be clearer.

Section to be re-phrased

All the sentences in 8-3 are to be shrunk for visibility.

We will rewrite the sentences so that the sentences are definition of dependability allocation argument, and reduce the size of the sentences as possible

Old
Figure 8-1 depicts DAC templates for Dependability Allocation Argument. The DAC template for Dependability Allocation Argument represents that the allocation of dependability requirements of the target architecture is adequate. This template is recursively used for each sub-architecture. The term architecture is used for represents either “System of systems”, “System”, “Component”, or “Implementation” (see Architectural Concept in Clause 7.1). For example, if a system S consists of sub systems S1 and S2, and the threat and environmental list for S is derived as h1,…, hn, and the dependability requirement is D (derived from Dependability Requirements Analysis), then the top claim “C1: Dependability allocation of System S for each system/component/implementation is adequate” is decomposed into the following three sub claims: “C3: Dependability allocation of System S1 for each sub architecture is adequate”, “C4: Dependability allocation of System S2 for each sub architecture is adequate”, and “C2: Allocation of D1 to S1, Allocation of D2 to S2 are adequate.” In this argument, the dependability requirement D is divided into D1 and D2, and they are allocated to S1 and S2, respectively. C3 and C4 are then decomposed into sub claims using this DAC template, according to the structure of S1 and S2, respectively. The adequacy of the decomposition of D into D1 and D2 is assured in the argument of sub claim C2. Threat and environment list for S: T=h1,…,hn is divided into T1 and T2. This division is derived as the result of Dependability Analysis of DPM. Note that the sum of T1 and T2 is not necessarily equals to T: the sum may be less than T.
The XMI file for the DAC template for Dependability Allocation Argument is DependabilityAllocationArgument.xmi (normative).

New
Change points: remove ":" in sentences and figure 8-1
Change all figures into PDF.

Figure 8-1 depicts DAC templates for Dependability Allocation Argument. The DAC template for Dependability Allocation Argument represents that the allocation of dependability requirements of the target architecture is adequate. This template is recursively used for each sub-architecture. The term architecture is used for represents either “System of systems”, “System”, “Component”, or “Implementation” (see Architectural Concept in Clause 7.1). System S consists of sub systems S1 and S2 (this template assume two sub systems, but the number can be modified according to the target system), and the threat and environmental list for S is derived as h1,…, hn, and the dependability requirement is D (derived from Dependability Requirements Analysis), then the top claim “C1 Dependability allocation of System S for each system/component/implementation is adequate” is decomposed into the following three sub claims: “C3 Dependability allocation of System S1 for each sub architecture is adequate”, “C4 Dependability allocation of System S2 for each sub architecture is adequate”, and “C2 Allocation of D1 to S1, Allocation of D2 to S2 are adequate.” In this argument, the dependability requirement D is divided into D1 and D2, and they are allocated to S1 and S2, respectively. C3 and C4 are then decomposed into sub claims using this DAC template, according to the structure of S1 and S2, respectively. The adequacy of the decomposition of D into D1 and D2 is assured in the argument of sub claim C2. Threat and environment list for S: T=h1,…,hn is divided into T1 and T2. This division is derived as the result of Dependability Analysis of DPM. Note that the sum of T1 and T2 is not necessarily equals to T: the sum may be less than T.
The XMI file for the DAC template for Dependability Allocation Argument is DependabilityAllocationArgument.xmi (normative).

Some english language corrections in sysa/14-11-01:

1. Section 0.3 (PDF p12) "constitutes of five major elementary" -> "consists of five major elementary".

2. Section 1 (PDF page 15) "methodology of the dependability argumentation" -> "methodology for the dependability argumentation". Also "integrating the conventional system assurance approach" -> "integrating conventional system assurance approaches". Also "as we are not experts of other systems" -> "as the authors are not experts in other systems".

3. Section 2 (PDF page 15) "the clause" -> "clause" (2 places).

4. Section 3 (PDF page 15) "following normative document contains" -> "following normative documents contain".

5. PDF page 21 ""composed by" -> "composed of" (6 places)

6. PDF page 24 "system of systems of system" -> "system or system of systems"

7. References to "SPEM2" (10 places) should be references to "SPEM 2.0".

The wording is to be fixed

As for the comment 1, DAF 1.0b1 has no section 0, so it is no longer relevant.

As for the comments 2 to 7, we would like to agree to revise them as you suggested.

1. Section 0.3 (PDF p12) "constitutes of five major elementary" -> "consists of five major elementary".
2. Section 1 (PDF page 15) "methodology of the dependability argumentation" -> "methodology for the dependability argumentation". Also "integrating the conventional system assurance approach" -> "integrating conventional system assurance approaches". Also "as we are not experts of other systems" -> "as the authors are not experts in other systems".
3. Section 2 (PDF page 15) "the clause" -> "clause" (2 places).
4. Section 3 (PDF page 15) "following normative document contains" -> "following normative documents contain".
5. PDF page 21 ""composed by" -> "composed of" (6 places)
6. PDF page 24 "system of systems of system" -> "system or system of systems"
7. References to "SPEM2" (10 places) should be references to "SPEM 2.0".

In section 9.1 of sysa/14-11-01 (Iterative and Rapid Process) - is this section normative or informative? If the latter, please label it as such.

The section 9.1 is to be modified.

The section 9.1 needs to stay normative to be modifed as follows;

Original
9.1 : Iterative and Rapid Process

New
9.1 : Overview of Iterative and Rapid Process

Section 8.1 (Introduction) should be labelled "Non-normative"

Informative instead of non-normative

OLD :
Label Section 8.1 Introduction

NEW :
Label Section 8.1 Introduction (Informative)

DAC SACM XMI files are not the newest ones. They should be updated

Keep to Use SACM 1.0

SACM 1.1 is the latest SACM specification. However it does not include schema file for the sacm xmi, which makes hard to submit our DAC templates in compliance with SACM 1.1. Therefore we will propose to keep using SACM 1.0 as we originally did in Beta one. The attachment contains the original SACM 1.0 xmi just for reference.

Section 6.2
"Now, given the fact that SSCD is a system to work for certain function, which aggregates systems to individually work for certain different function,"
This phrase needs to be clarified. What does "work for a certain function mean"?

Proposal to rephrase the sentence

Original : Section 6.2
"Now, given the fact that SSCD is a system to work for certain function, which aggregates systems to individually work for certain different function,"

New : Section 6.2
"Now, given the fact that SSCD is a system to implement certain function, which aggregates systems to individually implement certain different functions,"

6.1 Background and Rationale
Would the existence of this specification made the analysis easier, solved the problem, or prevented the problem from occurring? It is a fair question given the use of the example as a rationale for the creation of the spec. Also, does this improve on ISO 26262, which is the automotive safety standard?

A Use Case is conducted

An experiment of the DAF standard was conducted to prove the applicability for practical use, where the DAF was applied for the functional safety in automotive industry. A summary version of the use case is prepared as attached, which is going to be added in an annex.

9.3 Systems Engineering Process
There are a lot more activities in the systems engineering process. Not all are always necessary. You should mention that this is the required subset.

Proposal to add sentences

The following sentences are going to be added in the last part of Section 9.3

NEW sentences:
"There are a lot more activities in the systems engineering process, but not all are always necessary. These are the required subset."

Figure 7 12 - Error Model
I would have thought that a threat was made up of zero or more failures, errors and faults, with at least one of them existing. The multiplicity shows just one of each.
Also, Randam should be spelled random.

Model will be changed and typo be fixed.

According to Laprie's definition, which we use as a reference, the threat is a generic term for fault, error and failure. So we would like to suggest to remove all shared aggregations and place the Threat as a super-class of fault, error and failure.

We will revise the typo "Randam" as you suggested.

9.3.4.6 Code Generation
"The Code Generation activity is to generate Implementation Code. In this activity source code to be implemented in the target CPU is generated. It generates actually implemented Code as opposed to Auto-Coding results which cannot be flashed into the target CPU because CPU size constraints and poor failure mode implementation. "
Auto-coding can provide the correct code if the auto-generator is configured correctly. I have done so on several projects.

Proposal to add sentences

OLD : 9.3.4.6 Code Generation
"The Code Generation activity is to generate Implementation Code. In this activity source code to be implemented in the target CPU is generated. It generates actually implemented Code as opposed to Auto-Coding results which cannot be flashed into the target CPU because CPU size constraints and poor failure mode implementation. "

New : 9.3.4.6 Code Generation
"The Code Generation activity is to generate Implementation Code. In this activity source code to be implemented in the target CPU is generated. It generates actually implemented Code as opposed to Auto-Coding results which sometimes cannot be flashed into the target CPU because CPU size constraints and poor failure mode implementation. The auto-coded code is going to be further manually optimized for size or further manually enhanced with additional failure mode implementation "

Figure 9 4 - The Correct Control Software models Should this be called the software development process?

The name of figure is to be fixed

The process is going to be named as Software Development Process.

OLD : Figure 9-4 The Correct Control Software models

NEW : Figure 9-4 Software Development Process

All the diagrams in sysa/14-11-01 are bitmaps, and hence look fuzzy at high magnification. Please find a way to generate vector diagrams (such as SVG diagrams or vector PDF), to make sure that a final ("formal") OMG specification has a professional appearance.

All of the figures should be converted to the vector format.

All of the figures are converted from bitmap to SVG format.

Section 7.1.3 (Component) contains this sentence, which I cannot parse: "It is not almost a single Hardware and/or Software item, but compose several items of Hardware and/or Software."

The sentence is to be modfied.

Could we change like this? The sentence is gong to be removed and the previous sentence is going to be modified as follows;

OLD :
It is not almost a single Hardware and/or Software item, but compose several items of Hardware and/or Software.

NEW:
It consists Implementations that are more than one Hardware and/or Software.

Figure 7.8 ("Sample extension of Dependability Attribute") seems to be a non-normative example - please label it as such.

Suggestion taken.

We would like to revise it to "Figure 7-8 Sample extension of Dependability Attribute (Informative)" as suggested.

There are some multiple incoming arrows to activities.
Multiple incoming arrow means parallel merge.
In this case, loop-back arrow and initial arrow
are merged.
This means initial arrow (flow) should wait results
of subsequent arrow(flow).
It is impossible to perform this diagram.

*The multiple incoming arrows are going to be assigned appropriately. *

All activities with more than one incoming arrow are replaced with loop structure or exclusive-or. Figure 9-3 and 9-4 also had the same problem so we fixed and attached. The diagrams attached have a defect, which does not show the loop marker in pdf format. It appears that the tool we use has a bug, which does not produce the correct diagrams.

According to the description,
"System of Systems level is not mandatory".

This makes no sense.
If this isn't mandatory, it is not necessary to
define "System of Systems" here.

The description is to be modified.

It is going to be changed as follows.

There is an shared aggregation between "System of Systems" and
"System".
This means that subordinate parts exists independently,
that is, Brake system (and other systems) are installed to another vehicle after
previous one is disposed (or destroyed).
This shared aggregation is inadequate.

The multiplicity of the figure is to be modified.

Reflecting the comment, we changed the shared aggregation to Association. Also, the multiplicity of System of Systems is to be modified from 0..1 to 0 .. * as attached.

For example, a smart house (system) is in cooperation with other smart houses to form a smart community (system of systems) as the whole. There would be a case that a smart house does not belong to a smart community but shares data from other smart community. In this case, the relationship between the smart house and the smart community cannot be expressed by shared aggregation, therefore we changed it to association.

This is just an sample of issue.

It is just a sample of issue to get familiar with JIRA system. We don't need to track this issue any more.

It is just a sample of issue to get familiar with the JIRA. So, no issue.

The xmi for the figure 7-15 (Dependability Process Model) in DCM should be imported from SPEM2 xmi.

The figure 7-15 is to be modifed as attached.

All calsses (WorkSequence, BreakdownElement, WorkBreakdownElement, WorkSequenceKind) from the SPEM package were prefixed with SPEM2.

All of the classes mentioned above are now prefixed with the closest parental package name ProcessBehavior.

Character code of BPMN XMI is Shift-jis.

Fixed xmi file of BPMN

The xmi character code of BPMN was changed to ASCII from Shit-JIS.

In section 3, UML 2.4 is specified. Any reason why not to use UML 2.5?

Because UML 2.4 is an ISO standard.

See above.

In Section 0.4 "This specification is compatible with other OMG and Non-OMG standards." You should specify which ones, or reference the section where they are listed.

*The 0 section is removed in the Beta version. *

See above.

Figure 7 8 - Sample extension of Dependability Attribute Attributes normally are a single entity. It is odd that the attribute is composed of several other elements.

No change to be proposed

DAF spec already submitted has this amendment. So we would like to propose "closed and no change".

Figure 7 4 - Dependability Assurance Concept package I am surprised that there are not more dependencies between the packages.

All links are checked.

We have checked all the dependency links between the packages, which are drawn in the latest version beta 1. They are correct as they are.

"Additional Information" (Section 6) should presumably be labelled as non-normative. Section 6.5 "Changes to Adapted OMG Specifications" should be removed altogether.

Proposal to rephrase the titles for each section

The following changes are going to be proposed as normative. Could we agree on this?

Original :

6. Additional Information
6.1 Background and Rationale
6.2 General Introduction of DAF
6.3 Key Capabilities of DAF
6.4 Procedure
6.5 Changes to Adapted OMG Specifications
6.5 How to Read this Specifications

New :
6. Overview of the specification
6.1 Introduction
6.2 Key features
6.2.1 Key capabilities of DAF
6.2.2 Procedure
6.2.3 How to Read this specifications

In the conformance section (section 2) of sysa/14-11-01, it's not clear what is meant by "suggested conformance points". Are these "optional conformance points"? If so, what parts of the specification is it mandatory for implementers to provide to claim conformance to the specification?

Conformance section is to be modified

The "suggested" indicates ambiguity for comformance point. So, we are going to remove the word "suggested" to specify mandatory conformance points.

OLD :
In this Dependability Assurance Framework for Safety-Sensitive Consumer Devices (SSCD) Specification, suggested conformance points are Dependability Conceptual Model, Dependability Assurance Case, and Dependability Process Model. DAC templates shall confirm to SACM.
This specification is intended to be an umbrella specification, which allows several existing specifications/standards either by OMG or other standardization bodies in a single framework.

For any specification/standard of a specific SSCD to be in conformance with the Dependability Conceptual Model requires that the conceptual model of the standard/specification shall include all models in DCM. It shall extend DCM specified in this specification to support new dependability, assurance and process concepts for that specific SSCD as long as it will not cause any semantic inconsistency between DCM and the new conceptual model.

For conformance to Dependability Assurance Case, argumentation for SSCD dependability shall follow the argument structure specified in the clause 8.

For conformance to Dependability Process Model, the development process for SSCD shall follow the process defined in clause 9.

NEW :
This specification is intended to be an umbrella specification, which allows several existing specifications/standards either by OMG or other standardization bodies in a single framework.

For any specification/standard of a specific SSCD to be in conformance with the Dependability Conceptual Model requires that the conceptual model of the standard/specification shall include all models in DCM. It shall extend DCM specified in this specification to support new dependability, assurance and process concepts for that specific SSCD as long as it will not cause any semantic inconsistency between DCM and the new conceptual model.

For conformance to Dependability Assurance Case, argumentation for SSCD dependability shall follow the argument structure specified in the clause 8. DAC shall conform to SACM.

For conformance to Dependability Process Model, the development process for SSCD shall follow the process defined in clause 9.

In section 8.1 of sysa/14-11-01, this sentence: "Recently, the USA FDA (Food and Drug administration) requires safety cases for introducing infusion pump" should be re-phrased so that it will still make sense if read in 5 or 10 years' time.
A reference to this example, and also to the others in this paragraph, would be very useful.

Add the year 2010.

We will change the sentence as follows

OLD :
Recently, the USA FDA (Food and Drug administration) requires safety cases for introducing infusion pump.

->
NEW :
In 2010, the USA FDA (Food and Drug administration) requires safety cases for introducing infusion pump.

SACM 1.1 is the latest SACM specification. However it does not include schema file for the sacm xmi, which makes hard to submit our DAC templates in compliance with SACM 1.1. Compling with the SACM1.0 was raised with the issue # 70. Toward RTF, compling with SACM1.1 is required.

In 9.2, there is a description of Dependability Process. However, this explanation is poor. It is insufficient.
Besides, there is a description " System Engineerging Process", However, there isn't " System ENgineering Process" on the Figure 9-2.
Furhermore, clause 9.3 describes the "System Engineering Process". However, its diagram is slighly different from Figure 9-2. (For example, Figure9-2 includes "Development complete" branch, on the other hand, Fig 9-3 doesn't include it. Fig 9-2 includes "artifacts", however, FIg 9-3 doesn't include those. And, its branch condifition "Development continue" is ambigous.What is " Development conitue"?

In 9.2.1, According to the text, "Dependablity Analysis" talk about "threat" and "safety". From general definition, it is insufficient.