PUD(Point Unavailablity Density)の定義からご紹介します。とはいえ、これは弊社の造語であり本ブログと論文だけで通用するものです。このPUDは不稼働密度とでも訳すべきものであり、以下に定義を示します。

PUD:

PUD、すなわち不稼働密度$q_{item}(t)$は、前々回ご紹介したポイントアンナベイラビリティ(PUA)の時間微分で、以下の微小不稼働確率を$dt$で割ったものです。$q_{item}(t)$の式にすると$\lim_{dt \to 0}$が出てくるため、形式的に両辺に$dt$をかけ微小不稼働確率としています。 $$q_{item}(t)dt\equiv(\frac{dQ_{item}(t)}{dt})dt=\img[-1.35em]{/images/withinseminar.png}\tag{61.1}$$

PMHFは、修理系アイテムの車両寿命間のダウン確率の時間平均であることから、ここで示すアイテムの平均PUDと考えられます。このことは規格Part5には以下のように書かれています。

「アイテムの作動寿命間の毎時平均確率」とは舌足らずであり、何の確率かが書かれていません。その前に「ランダムハードウェア故障」とあるため文脈から故障確率であると読み取れますが、修理系の場合は厳密には故障確率ではなく、故障したものが修理される事象を含めたダウン確率です。

従って、PMHFを求めるにはまず微小不稼働確率に着目して確率微分方程式を立て、それを0から車両寿命$T_{lifetime}$まで積分し、$T_{lifetime}$で割って平均PUDを算出する流れで求めます。

前のブログ 次のブログ

ISO 26262のPMHFの導出の場合、微小確率の積分を実行する際に次の(60.1)及び(60.2)式が出てくるため、あらかじめ結果を導出しておき、後程積分公式として使用します。 $$ \frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(t) f_{M}(t)dt\tag{60.1} $$ 及び $$ \frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(u) f_{M}(t)dt,\ \ s.t.\ \ u:=t\bmod\tau\tag{60.2} $$ まず、(60.1)式に、$F_{SM}(t)=1-e^{-\lambda_{SM}t}$及び、$f_{M}(t)=\lambda_M e^{-\lambda_M t}$を代入し、 $$ \frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(t)f_{M}(t)dt=\frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}(1-e^{-\lambda_{SM}t})\lambda_{M}e^{-\lambda_{M}t}dt\\ =\frac{\lambda_{M}}{T_{lifetime}}\int_0^{T_{lifetime}}e^{-\lambda_{M}t}dt-\frac{\lambda_{M}}{T_{lifetime}}\int_0^{T_{lifetime}}e^{-(\lambda_{SM}+\lambda_M)t}dt\tag{60.3} $$ (60.3)の右辺第1項は、 $$ \require{cancel} \text{1st term of RHS of (60.3)}=\frac{\bcancel{\lambda_{M}}}{T_{lifetime}}\left[\frac{e^{-\lambda_{M}t}}{-\bcancel{\lambda_{M}}}\right]^{T_{lifetime}}_0=\frac{1}{T_{lifetime}}(1-e^{-\lambda_{M}T_{lifetime}})\tag{60.4} $$ (60.3)の右辺第2項は、 $$ \text{2nd term of RHS of (60.3)}=-\frac{\lambda_{M}}{T_{lifetime}}\left[\frac{e^{-(\lambda_{SM}+\lambda_{M})t}}{-(\lambda_{SM}+\lambda_{M})}\right]^{T_{lifetime}}_0\\ =-\frac{\lambda_{M}}{T_{lifetime}(\lambda_{SM}+\lambda_{M})}\left[1-e^{-(\lambda_{SM}+\lambda_{M})T_{lifetime}}\right]\tag{60.5} $$ ここで$\lambda t\ll 1$の条件で$e^{-\lambda t}$のMaclaurin展開は $$e^{-\lambda t}=1-\lambda t + \frac{1}{2}\lambda^2 t^2-O((\lambda t)^3)$$となるため、$O((\lambda t)^3)\approx 0$と近似し、これを(60.4)及び(60.5)に代入すると(60.3)は、 $$ \frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(t) f_{M}(t)dt \approx\frac{1}{\bcancel{T_{lifetime}}}(\lambda_{M}\bcancel{T_{lifetime}}-\frac{1}{2}{\lambda_{M}}^2{T_{lifetime}}^\bcancel{2})\\ -\frac{\lambda_{M}}{\bcancel{T_{lifetime}}\bcancel{(\lambda_{SM}+\lambda_{M})}} \left[\bcancel{(\lambda_{SM}+\lambda_{M})}\bcancel{T_{lifetime}} -\frac{1}{2}(\lambda_{SM}+\lambda_{M})^\bcancel{2}{T_{lifetime}}^\bcancel{2}\right]\\ =(\bcancel{\lambda_{M}}-\bcancel{\frac{1}{2}{\lambda_{M}}^2T_{lifetime}}) -\lambda_{M}\left[\bcancel{1}-\frac{1}{2}(\lambda_{SM}+\bcancel{\lambda_M})T_{lifetime}\right] =\frac{1}{2}\lambda_{M}\lambda_{SM}T_{lifetime}\tag{60.6} $$ 以上から(60.1)の値が求められました。

結果のMとSMに関する対称性から推測可能なように、(60.6)においてMとSMを入れ替えた次の式も同じ値となります。 $$ \frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{M}(t) f_{SM}(t)dt\approx\frac{1}{2}\lambda_{M}\lambda_{SM}T_{lifetime}\tag{60.7} $$ 次に(60.2)式はやや複雑になりますが、基本的には同様な計算を行います。まず、$u:=t\bmod\tau$であることから、$t=i\tau+u, i=0, 1, 2, ..., n-1, T_{lifetime}=n\tau$とおき、$t$を$i$と$u$で表せば、 $$ \frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(u)f_{M}(t)dt =\frac{1}{T_{lifetime}}\sum_{i=0}^{n-1} \int_0^{\tau} (1-e^{-\lambda_{SM}u})\lambda_{M}e^{-\lambda_{M}(i\tau+u)}du\\ =\frac{\lambda_{M}}{T_{lifetime}}\sum_{i=0}^{n-1}e^{-\lambda_{M}i\tau}\int_0^{\tau}e^{-\lambda_{M}u}du -\frac{\lambda_{M}}{T_{lifetime}}\sum_{i=0}^{n-1}e^{-\lambda_{M}i\tau}\int_0^{\tau}e^{-(\lambda_{SM}+\lambda_M)u}du\tag{60.8} $$ ここで、$\sum_{i=0}^{n-1}e^{-\lambda_{M}i\tau}$を計算すると、等比数列の和及びMaclaurin展開の1次近似より、 $$ \sum_{i=0}^{n-1}e^{-\lambda_{M}i\tau} =\frac{1-e^{-\lambda_{M}T_{lifetime}}}{1-e^{-\lambda_{M}\tau}} \approx\frac{\bcancel{\lambda_{M}}T_{lifetime}}{\bcancel{\lambda_{M}}\tau} =\frac{T_{lifetime}}{\tau} $$ よって、(60.8)の右辺第1項は、 $$ \text{1st term of RHS of (60.8)}=\frac{\bcancel{\lambda_{M}}}{\bcancel{T_{lifetime}}}\frac{\bcancel{T_{lifetime}}}{\tau}\left[\frac{e^{-\lambda_{M}t}}{-\bcancel{\lambda_{M}}}\right]^{\tau}_0 =\frac{1}{\tau}(1-e^{-\lambda_{M}\tau})\tag{60.9} $$ (60.8)の右辺第2項は、 $$ \text{2nd term of RHS of (60.8)}=-\frac{\lambda_{M}}{\bcancel{T_{lifetime}}}\frac{\bcancel{T_{lifetime}}}{\tau}\left[\frac{e^{-(\lambda_{SM}+\lambda_{M})t}}{-(\lambda_{SM}+\lambda_{M})}\right]^{\tau}_0\\ =-\frac{\lambda_{M}}{\tau(\lambda_{SM}+\lambda_{M})}\left[1-e^{-(\lambda_{SM}+\lambda_{M})\tau}\right]\tag{60.10} $$ 同様にMaclaurin展開の2次近似を(60.9)と(60.10)に用いると、(60.8)は、 $$ \frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{SM}(u) f_{M}(t)dt \approx\frac{1}{\bcancel{\tau}}(\lambda_M\bcancel{\tau}-\frac{1}{2}\lambda_M^2\tau^\bcancel{2})\\ -\frac{\lambda_{M}}{\bcancel{\tau(\lambda_{SM}+\lambda_{M}})} \left[\bcancel{(\lambda_{SM}+\lambda_{M})\tau} -\frac{1}{2}(\lambda_{SM}+\lambda_{M})^\bcancel{2}\tau^\bcancel{2}\right]\\ =(\bcancel{\lambda_{M}}-\bcancel{\frac{1}{2}{\lambda_{M}}^2\tau}) -\lambda_{M}\left[\bcancel{1}-\frac{1}{2}(\lambda_{SM}+\bcancel{\lambda_M})\tau\right] =\frac{1}{2}\lambda_{M}\lambda_{SM}\tau\tag{60.11} $$ 以上から(60.2)の値が求められました。

これも結果のMとSMに関する対称性から推測可能なように、(60.11)においてMとSMを入れ替えた次の式も同じ値となります。 $$ \frac{1}{T_{lifetime}}\int_0^{T_{lifetime}}F_{M}(t) f_{SM}(u)dt\approx\frac{1}{2}\lambda_{M}\lambda_{SM}\tau\ \ s.t.\ \ u:=t\bmod\tau\tag{60.12} $$

前のブログ 次のブログ

※この記事は2018年に書かれたものであり、基本的には変わりませんが最近の記事で詳細計算を行っています。

SMのアンナベイラビリティ(不稼働率、PUA)$Q_{SM}(t)$の導出

以前PMHF式を以下で導出しました。 https://fs-micro.com/post/show/id/10.html

ここでは再度PMHFの式を導出して行きますが、事前準備がいくつか必要になりますので、まず、修理系のアンナベイラビリティの公式を導きます。

まず、修理系とは何かを説明します。ISO 26262規格には修理の問題についてはっきり書いていませんが、1st SMが修理系となります。1st SMとは、1st order SMとも呼ばれ、主機能のSG侵害(安全目標侵害=VSG)を防止するためのSMです。一方で、主機能は非修理系です。

1st SMは、2nd SMにより定期的に検査され、故障だと判明した場合は直ちに修理されます。2nd SMとは2nd order SMとも呼ばれ、エレメントがレイテントフォールトとなるのを防止する安全機構です。規格にもあるとおり、修理周期は「検査周期($\tau_{SM}$)＋ドライバーが修理工場へ運転して行く時間＋修理にかかる時間」です。従って、修理周期＝2nd SMの検査周期とみなせます。

規格にははっきり書かれていませんが、検査により故障と判明した部分については、修理され新品同様(as good as new)と見なされます。この検査による故障検出割合が重要であり、Part 10では定数値$K_{FMC,MPF}$で表されます。故障したうちの検出部分なので(59.1)のように条件付き確率と考えがちですが、 $$K_{FMC,MPF}=\Pr\lbrace \text{detectable}\ |\ \text{failed at }t \rbrace\tag{59.1}$$ 故障検出能力は確率的に決まるものではなく、アーキテクチャ的に決まるものだと考えるため、もともとの検出部分の故障について検出可能とします。 $$K_{FMC,MPF}=\Pr\lbrace \text{detectable} \rbrace\tag{59.2}$$ 検出された故障は全て修理されるものとします。 $$\Pr\lbrace \text{repaired}\ |\ \text{detected at }t\rbrace=1\tag{59.3}$$

次にアンナベイラビリティ$Q_{SM}(t)$とは、省略せずに言うとポイントアンナベイラビリティ(PUA)であり、修理系の不稼働率です。 確率の式で表せば、

PUA: $$Q_{SM}(t):=\Pr \lbrace \text{(repairable)SM down at }t \rbrace\tag{59.4}$$ のように、時刻$t$において不稼働である確率を意味します。

一方で、アベイラビリティの式は参考ページまたはBirolini教授の教科書を参照すれば、 $$ A(t):=R(t)+\int_0^t m(x)R(t-x)dx\tag{59.5} $$ であり、ここで、$A(t)$は時刻tにおけるポイントアベイラビリティ、$R(t)$は時刻tにおけるリライアビリティ(信頼度)、$m(t)$は時刻tにおけるリニューアル密度(修理密度)です。規格の特徴として、修理周期は教科書一般にあるように指数関数分布はとらず、定期的に$\tau_{SM}$毎に行われるため、以下の式が成立します。 $$A_{SM}(t)=R_{SM}(t)+K_{SM,FMC,MPF}F_{SM}(\tau_{SM})\sum_{i=0}^{n-1}R_{SM}(t-i\tau_{SM})\tag{59.6}$$

修理分$K_{SM,FMC,MPF}F_{SM}(\tau_{SM})$が時刻$t$の関数でないのは、検出能力$K_{FMC,MPF}$は一定で、かつ毎回の故障確率も一定で、検出した分は全て修理されるため、修理分が一定となるためです。 従って、SMのポイントアベイラビリティ式は以下のようになります。 $$A_{SM}(t)dt=\img[-1.35em]{/images/withinseminar.png}\tag{59.7}$$

これを1から引けば、SMのポイントアンアベイラビリティ(PUA)は以下のように求められます。

PUA: $$Q_{SM}(t)dt=\left[1-A_{SM}(t)\right]dt=\img[-1.35em]{/images/withinseminar.png}\tag{59.8}$$

(59.8)の両辺を時刻$t$で微分すれば、微分可能な$t$におけるPUD(Point Unavailability Density)が求められます。

PUD: $$q_{SM}(t)dt:=(\frac{dQ_{SM}(t)}{dt})dt=\img[-1.35em]{/images/withinseminar.png},\\ \ t\notin\{\tau_i=i\tau; i=1,2,...,n\}\tag{59.9}$$

※ここでの議論において、次に示すような形式的な記法を用いています。例えば、 $$f(t)=\lim_{dt\to +0}\frac{F(t+dt)-F(t)}{dt}=\frac{dF(t)}{dt}$$ と書くところを$dt$が無限小であることを前提として、 $$f(t)dt=dF(t)$$ としています。確率密度関数$f(t)$を求めるよりも、微小確率$f(t)dt$を求めるほうが、次での積分の記述が容易になるためです。

なお、本稿はRAMS 2025に投稿予定のため一部を秘匿しています。

前のブログ 次のブログ

アセッサー目線からみると、ASILが食い違うところはまずチェックします。当然ですが、低ASILから高ASILの、例えば図のように、ASIL-Bのエレメントからの信号をASIL-Cのエレメントで受けているような場合。しかしながら、規格Part9 6.4で述べられているように、QMないし低ASILの要求を割り当てられたエレメントは、ASILないし高ASILの割り当てられたエレメントへ干渉してはいけません。

干渉がある場合には、エレメントを高いASILへ引き上げる必要があります。これが前回も述べた、共存の基準と言われる規格要件です。

専門家(日本の機能安全関連団体の委員)の資料で、「無干渉は従属故障が無いこと」と書いてあるものを見ましたが、これは誤りです。無干渉とは、Part1-1.49に示されるとおり、カスケード故障が無いことです。従属故障というと、カスケード故障と共通原因故障の両方を含みます。 また同じ資料で、「干渉は片方からの故障の影響であり、独立は相互に故障の影響が無いこと」と書かれていましたが、これも誤りで「独立とは従属故障が無いこと」と規格で定義されています。

このように、専門家といえども規格の文言を誤解していることが無いとは言えないので、盲信せず聞く必要があると思われます。

前のブログ 次のブログ

デコンポジションの基本的な考え方は理解頂いたと思うので、同様に重要な要件を説明します。 同じくPart9に記載されている「共存の基準」です。

1. QMエレメントからASILエレメントへの無干渉を証明すれば、QMエレメントとASILエレメントが共存することができる。さもなければQMエレメントはASILエレメントのASILまでASILを引き上げなければならない。

2. 低ASILエレメントから高ASILエレメントへの無干渉を証明すれば、低ASILエレメントと高ASILエレメントが共存することができる。さもなければ低ASILエレメントは高ASILエレメントのASILまでASILを引き上げなければならない。

いずれも同様な要件であり、QMないし低ASILエレメントはいわば濁った水です。一方で高ASILエレメントはきれいな水です。従って、高ASILエレメントがQMないし低ASILエレメントに干渉しても、濁ったままで問題ないのに比べて、その逆の場合は、きれいな水が濁った水になってしまいます。従って、無干渉が証明できない限り濁った水をきれいにしてやる必要があるということです。

規格Part9 6.4.4及び備考1を見てみましょう。

これはQMからASIL付与エレメントへの無干渉条件(カスケード故障無き事)ですが、前述のとおり、低ASIL付与エレメントから高ASIL付与エレメントへの同様の条件があります。それが規格要件Part9 6.4.5です。

前のブログ 次のブログ

前回は規格の条文に基づいて、ISO 26262におけるASILデコンポジションの原則を説明しましたが、実際にどのように設計するかを説明します。

あるECUがあり、それに対するASILは最高ASILであるASIL-Dだとします。その理由は、このECUが走る、曲がる、止まるに関係しており、高速道路上で故障した場合に、人命に影響するためです。安全目標はそのように定められており「意図せず走行中にECUからアクチュエータへ特定機能のON信号を出力しないこと」となります。本機能はマイコンのソフトウェアで実装されています。

注意点として、ASILデコンポジションはシステマティック故障が対象なので、主にソフトウェア開発のASIL引き下げに有効です。従ってこのマイコンのASILを下げることを考えます。

マイコンはノイズ等で誤動作する可能性があることから、まず初期安全要求を冗長化します。マイコンへの初期安全要求は「意図せず走行中にマイコンから特定機能のON信号を出力しないこと」。ここで、「意図せず」というのは、「設計意図と異なり」という意味で、実際には「故障したとき」と読み替えると意味が通ります。「意図せず」という文言は省略されることがあります。

冗長化された安全要求はTSR1=「走行中にマイコンから特定機能のON信号を出力しないこと」、TSR2＝「走行中にマイコンから特定機能のON信号を出力しないこと」と同じ内容の安全要求となります。これをエレメント独立要求を満足するようにエレメント分割すると、メインマイコンとサブマイコン、ないしはメインマイコンとハード制御と分割できます。このRBD(Reliability Block Diagram)を書けば、言うまでもなく並列系となります。

ここではハード回路で制御する方法を考えると、走行中にマイコンからの特定機能のON信号のスイッチを切れば良いわけで、比較的簡単な回路で実装可能です。当然、メインマイコンとハード回路の間は独立性が必要であり、独立とは従属故障、すなわちカスケード故障と共通原因故障のいずれも無いことを意味します。

ここで、規格のPart9 5.4.7 a)にあるように、安全機構のASILを高くしてASIL-D(D)、マイコンをQM(D)とデコンポジションすることができます。マイコンのソフトウェアは従来開発を流用できるため、コストの高い機能安全開発から免れることができます。

前のブログ 次のブログ

業界ではASILデコンポジションについての誤解が幅広くみられるため(経験では99%)、説明します。

ASILをいきなりエレメントに与えるのは誤り

あるティア1では、ECUを設計する際にOEMから安全目標を頂いたところ、ASIL-Cでした。走る曲がる止まるに関連し、もし故障した場合のリスク度合が高いため安全目標がASIL-Cとなっています。流用開発のためブロック図はだいたい固まっています。このティア1はASILデコンポジションを前提として、MCUは従来開発をキャリー(オーバー)したいので、MCUにQMを割り当てました。しかし、これは誤りです。

本来、安全目標があり、それをシステムレベルの初期安全要求に分解しますが、安全要求がASILの属性を持つことに注意してください。エレメントは安全要求を割り当てられてはじめてASIL値を持つことになります。

つまり、要求も無しにエレメントのASILを決定することはできません。要求分解よりも先にエレメントのASILを決めてしまいましたが、これでは本末転倒です。この誤りは前述のように経験上99%の顧客に当てはまります。

ところで、ASIL-CのSPFMの目標値は97%以上と非常に高く、ほぼすべてのエレメントが故障検出されるといっても良いくらいです。また最高難度であるASIL-Dの99%以上と比べてほとんど違いが無いため、欧州ではASIL-CとASIL-Dは同様なプロセスやアーキテクチャを適用することが多いようです。

一方、この誤りの原因は理解でき、ソフトウェアは安全機構でバックアップした上で、なるべくQMで開発したいところです。そのためにISO 26262規格ではASILデコンポジション(ASIL分解)というテーラリング手段が用意されています。

ただし、ASILデコンポジションが可能なのは以下の2つの要件が満足されるときに限られます。

1. 安全要求の冗長性
2. 安全要求の割り当てられたエレメント間の独立性

まず、1.は規格Part9 5.4.4に

とあります。普通の場合、初期安全要求は複数の安全要求に分解され、分解された安全要求を合わせて初期安全要求を満足します。ASILデコンポジションは例外で、分解された安全要求は単独で初期安全要求を満足しなければなりません。備考にもあるようにこれは冗長性を意味します。これは、エレメントの機能失陥により一方の安全要求が達成されなくても、他方の安全要求が割り当てられたエレメントにより初期安全要求が担保されることを意味します。

次に2.は規格Part9 5.4.6に

とあるように、分解された安全要求が割り当てられたエレメントはお互いに独立でなければなりません。独立とは、Part9 5.4.11 b)にあるように、従属故障分析を行った上で、その故障原因を発見できない場合、あるいはコントロールされる場合という意味です。この従属故障とは、カスケード故障と共通原因故障の両者を意味します。

これら2つの要件をまとめて表すと次の規格要求となります。

それではどうすれば良かったのかといえば、$\img[-0.9em]{/images/withinseminar.png}$ このような方式は、規格でも推奨しています。

前のブログ 次のブログ

MBSE

モデルベースデザインの成功例としてマツダの例がしばしば取り上げられます。主任設計者の方のインタビューでは、「金が無いからモデルベースを進めた」ということをおっしゃられていました。実機を作成するには費用がかかりますが、時間もかかります。モデルであれば、作成も修正も(慣れれば)容易です。結果的にModel In the Loopの手法で他社よりも早く開発することができました。モデルベースの開発のメリットは早さだけでなく、ステークホルダー(利害関係者)の間で仕様の認識違いの無いことを、従来の自然言語ベースの仕様書よりも担保しやすくなります。一方で、従来のドキュメントよりも抜け漏れが無いように作りこむことから、しばしば工数は(そこだけ見ると)増加します。

SysML

従来モデル記述言語にはUMLがありましたが、UMLはその仕様が大きくて使いにくい面があり、近年はSysMLを使うユーザが増加しています。SysMLは2006 年 7 月に OMG (Object Management Group) により仕様が策定された言語でUMLを一部使いやすく制限し、一部で拡張しています。拡張の部分の大きな点は要求図を入れたことであり、これは大きな進歩だと考えています。なぜならISO 26262では安全要求ベースで開発が進むためです。具体的には、大きな安全要求、つまり大目標のことを安全目標と呼び、それを抽象度を下げることにより、細分化していきます。抽象度を下げるとは、最初機能であったエレメントのつながりが、最後には物理的なエレメントのつながりに変化していくことを意味します。つまり、要求の抽象度を下げるというよりも、それを割り当てるエレメントを細分化していき、結果として要求が細分化されます。その中で、機能であったエレメントがハードエレメント、ソフトエレメントに細分化されます。

これは設計プロセスそのものですが、抽象的に表現してもわかりにくいので、前回は出張を例にとり具体的な例で示しました。

SysMLに関して大変参考となるページがあるので、ご紹介します。

http://www.ogis-ri.co.jp/rad/webmaga/rwm20100806.html

前のブログ 次のブログ

要求

要求について考えてみましょう。ところで似たような言葉に要求と要件とがあります。似たような概念であるため、混用して使用されることも多いですが、ここでは異なる意味として定義をはっきりさせておきたいと思います。

まず要求ですが、顧客の要求を意味することが多いです。顧客要求は文字通り顧客の要望であり、それは整理されておらず、たまには矛盾する要望が存在します。それが開発側に伝えられるわけですが、開発側はそれをシステマティックに整理し、矛盾は取り除き、開発側の要件とします。従って、同一のようなものでありながら、顧客からリリースされた時点では要求であるのに比べて、要求分析を実施し、再定義することにより要件となります。

仕様

それでは仕様とは何でしょうか。要求も仕様も、これもまた混用して用いられますが、本来ははっきりと異なった意味があります。以下の参考URLを見て頂ければわかりますが、端的には要求(要件)はWhatであり、仕様はHowだということです。要求は、方法はともかくこのように動いて欲しいという振る舞いを機能的に(=機能要求)、非機能的に(=非機能要求)表すのに対して、仕様はどのようにそれを実施するかを記述します。

https://wellfire.co/learn/requirements-and-specifications/

要求と仕様の具体例

要求を細分化して実現可能な仕様に落としていく作業のことを「設計」と呼びますが、抽象的な概念であるため、理解のために具体例を挙げてみます。例えばあなたが支社に勤務しているとして、上司から「本社に出張してくれ」と言われたとします。まぎれもなくこれは要求です。手段はどうあれ、物理的に移動することが目標となります。もちろん、暗黙の非機能要求として「時間、費用を最小にしてくれ」という要求もあります。従って、支社から本社に一足飛びにヘリコプターで行くのは採用できません。公共交通機関を利用するとして、支店もよりのA駅、本社最寄りのB駅を結ぶ鉄道を思い浮かべます。

この頭の中で一瞬で行うのはおおまかな「支社→本社」という要求を実現可能な手段に合わせて「支社→A駅」(徒歩)、「A駅→B駅」(鉄道)、「B駅→本社」(バス)という要求に分割したことにほかなりません。これは出張を設計したことになります。

安全設計

ここまでは機能安全に関係ない、一般の設計でしたが、ここからが関係してきます。出張においての安全設計とはなんでしょうか？例えば前記本社への出張で、鉄道が不通になったら「鉄道が不通になったのでいけません」ということになります。重要な会議の場合は「なんとしてでも行ってくれ」ということになると思います。 機能安全では回路の中でも重要とそうでないものを識別するように要求されており、安全に関連するものとしないものを区別する必要があります。安全に関連するものは、場合によってはどうしても達成する必要があります。この場合のどうしてもというのは、例え一点故障があってもの意味合いです。 さて、出張に戻り安全設計を考えると、本来の要求の冗長の要求を導出します。導出といっても同じ要求のコピーです。ただし、異なる手段が必要となります。例えばA駅とB駅間で私鉄とJRが並走していれば、別の鉄道を使うことになります。そうでない場合は、例えば「支社→C駅」(バス)、「C駅→D駅」(別の鉄道)、「D駅→本社」(バス)ということになります。

前のブログ 次のブログ

システム工学

近年システム工学の隆盛により、自動車分野にもその流れが来ています。その中で、次第に上流まで言語設計をする動きがあります。その理由は、従来ドキュメント(紙)により仕様を関係者に伝え、順次具体化して来ていたわけですが、その行き詰まりが、特にソフトウェア分野で顕著なためです。関係者の例としては顧客、サプライヤー間、サプライヤー、ソフトウェアハウス等があり、様々な局面で仕様がブレークダウンされ取り交わされます。

車載ECUの開発は、ハードウェアよりもソフトウェアに多大な工数がかかるのは良く知られており、デバッグに大変な労力をかけています。それは仕様の思い違いだったり、ユースケースの抜け漏れだったり、単なる論理ミスだったり様々な原因がありますが、仕様に関するものだと、場合によるとテストもその仕様で作成された場合にはテストでバグを検出することができません。

バグは入れなければ取る必要も無いことから、ソフトウェアの自動生成が考えられてきました。このようにしてコンピュータの言語の歴史はコンピュータに近いほうから、アセンブリ言語、コンパイラ言語、システム言語(ドメイン固有言語)と進化してきました。システム言語は、人も含めたあらゆるシステムを、ユースケース図、シーケンス図、状態遷移図、ブロック図等の人間が紙に記述してきたドキュメントをなるべく形式的な形で、自然言語を使わない形でコンピュータに取り込むことを目指しています。この取り込む形のことをモデルと呼び、ここで述べたような設計手法のことを、モデルベースシステム工学、簡単にはモデルベース設計と呼びます。

前のブログ 次のブログ