Bookmark and Share
Blog powered by Typepad
Member since 03/2007

Become a Fan

« Regression Analysis | Main | Eliminating Classes of Errors »

September 21, 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.


do you think so

Lizard Labs

Well... round about every blog posts online don't have much originality as I found on yours.. Just keep updating much useful information so that reader like me would come back over and over again.


It means the archive where the software life cycle data is maintained after a formal release. This ensures that no unauthorized changes can be made to those items. The storage medium is irrelevant. The DVD/tape version is probably simply a back-up. You need to refer to Section 7.2.7 of DO-178B for a further explanation of the archive.

Bharathi Raja

Here "an Archive " means can i consider Configuration database(VSS in our case) where we updated lifecycle data for next version OR Magnetic tape or DVD which we use to archive Configuration database for release and as backup??


This bullet is requesting the Applicant to provide a reference to (or copy of) those procedures that the development orgainisation would use to recover the source code, software life cycle data and software life cycle environment from an archive for, typically, the purposes of subsequent modification of the software to produce a new release software product.

Bharathi Raja

What does the DO-178B section 11.16 point G("The procedures used to recoverv the software for regeneration, testing or modification.") asking for??

Bharathi Raja

Okay. That is not a requirement for us to just explain scenario i took it.

When i read "Rationale for Safety-Related Design Decisions" I thought that "if I have alternative Design method (Two or more) to implement a High level requirement then i need take Design Decisions in this case i need to write Rationale to tell why the particular Design method is chosen.


I would recommend the rationale for this on the following lines:

Writing High and LOW alternatively on pin SGPIO_A_16 resets the Watchdog.

The requirement in this case looks self-explanatory, but this may not be the case always.

Hope this helps,

PS: I am assuming you have not reproduced the requirements verbatim. That could get you into unnecessary hassle.

Bharathi Raja

We have unique ID (Tag) for each Requirements (Both High level and Low level) and each associated with the additional safety attribute just to tell TRUE or FALSE but we have not written anything Rationale as we thought it is directly derived from High level requirement (other words it’s just doing what High level requirement told).

For example
HL SW Req No. 001.0024 :The software shall reset watch dog for every 100msec.
Safety Related: TRUE

LL SW Req No. 001.0024.0312 : The software shall write High and LOW alternatively on pin SGPIO_A_16 on every 50msec.
Safety Related: TRUE


@Bharathi, I am sure you did not mean it, but just to clarify: You cannot use the same tag in two places. Each tag needs to be unique.

Merely tracing SDD tags to the Systems Safety tags is not sufficient. You need to writw a note below the SDD tag indicating how your SDD requirement satifies the Systems Safety requirements.

Example: Let's assume you have a critical timing related system requirement. And suppose you have a few timer related requirements that all trace to the systems requirement. The rationale for the traced SDD requirements should show which oart of the safety requirement is addressed and how.
(SDD_Req/786: The fault flag shall be latched if time > 80% of Total Time.
Rationale: The flag is set to signal a cuation. The flag is latched to ensure that the caution is retained for at least three minor cycles; Refer SDD_Req/108.) - just an example I pulled out of my hat; does not mean a thing.

Bharathi Raja

1. We already have tag which tells System Requirements is a Safety related or not. Now is it enough to meet this objective "if we provide same tag for Low Level design Requirements"??
2. We have already provided rationale for derived Low Level design requirements (Even though none of them are safety related). But what rationale required for the Low Level design Requirements which are traced to Safety related system Requirements (other than tagging it as safety related)??

The comments to this entry are closed.

My Photo

Life sometimes turns on a dime. Especially when you are actively looking out for a change. I now work at HCL Technologies. And all I am looking for is to make a difference. By the way, the blog contents remain my own. It does not reflect the official position of HCL.

Your email address:

Powered by FeedBlitz