サービス

設計を、現場に出る前に検証する。

私たちが提供するのは、御社の設計から出た具体的な不具合と反例です。概念の説明ではありません。まずは小さく、御社の設計ひとつで確かめてください。

設計検証診断

入口となるサービスです。

開発中のシステム、導入を検討中の部品ひとつ、あるいはいま動いている装置の改造を対象に、設計段階での検証を実施します。実機は必要ありません。

ただし、検証には設計が読み取れる形になっている必要があります —— 動作の条件、状態、インターロックが文書から追えることです。この形になっていない場合は、検証できる設計書にすることを前段の作業として、別途お見積りします。

改造の場合も同じです。読むのは図面と設計文書であって、既存の制御ソースコードからモデルを復元することは行っていません。手元にあるのがコードだけの場合、まず設計文書に起こすところからのご相談になります。

装置ソフトウェアの検証は、これまで統合テストと現場立ち上げまで待つしかありませんでした。診断は、その待ち時間を設計段階まで引き上げます —— 誤りが最も安く直せる時点まで。

成果物

設計問題レポート

設計のどこに、どのような問題があるか。次の設計レビューにそのまま持ち込める形で。
反例シナリオ

問題を再現する正確なイベント列。「どこかがおかしい」ではなく、再現手順そのもの。
安全性質の証明

モデル化した範囲において、危険シナリオが「構造的に到達不可能」であることの証明。前提と検証範囲を明示したうえでお渡しします。テストの「やってみたが起きなかった」とは、根拠の質が違います。

検証が範囲内で結論に至らなかった場合は、どこまで確認できたかと、その理由を報告します。

診断で報告すること

結果は、抽象的な安心ではなく具体的な形で報告します —— 検証した範囲、確認できた安全性質、見つかった設計欠陥とその再現手順。

欠陥の数をお約束するものではありません。欠陥が見つからないことも、範囲を明示したうえでの結果です —— その場合、御社の設計はその範囲において健全だった、ということです。

検証の前段を、こちらで引き受けます。

検証を始めるには、設計が検証できる形になっている必要があります。しかし現場の設計書は自然言語で書かれ、前提の多くは熟練者の頭のなかにあります。この移し替えの手間が、形式手法の実際の導入障壁です。

この作業を、私たちが引き受けます。自然言語の設計書を、検証可能な仕様の形に移す —— これ自体を独立したサービスとして提供します。

副次的な効果

形式化された設計書は、検証の入力であると同時に組織の資産になります。設計のノウハウが検証可能な形に変われば、技術は人ではなく組織に残る。担当者の異動や退職で失われる暗黙知が、読める形で残ります。

前提と範囲

検証の値打ちは、確かめた範囲を正確に述べられることにあります。範囲を曖昧にしたまま「安全になります」と言う会社は、信用しないでください —— 私たちも含めて。

境界は三つです。いずれも、着手前に文書で確認します。

01

確かめるのは、設計です

その設計どおりに実装されているか、配線が合っているか、実機のモータが想定時間で止まるか —— 検証はこれらについて何も言いません。テストは減りません。減るのは、テストで見つけるつもりだったのに見つからなかった一群です。
02

証明は、合意した問いの分だけです

「両軸が同時に共有領域に入らない」を確かめたなら、確かめられたのはそれだけです。三軸目も、非常停止からの復帰も、含まれていません。何を検証するかは、着手前に文書で合意します。
03

調べられる大きさに、収める必要があります

状態の組み合わせは対象の規模に応じて急激に増えます。だからモデルは抽象化であり、何を捨てるかの判断が入ります。その判断と、それによって検証の対象外となった範囲も、報告に含めます。

その先

最初から大きく始める必要はありません。診断ひとつで、御社の設計に対して何が出てくるかは分かります。

どの装置のどの部分を対象にすべきか分からない場合も、そこからご相談ください。