どこに、どんな欠陥があるか
設計のどの部分に問題があるかを、場所を特定した一覧でお渡しします。
毎年、静かに
どの装置メーカーにも、帳簿に名前のつかない出費があります。
現場に出てから見つかる設計の問題です。原因を探すのに何日もかかり、納期が遅れ、つくり直しになる。ときにはリコールや安全上の問題にまで及びます。
この費用は、どの勘定科目にも「設計の欠陥」とは書かれていません。だから経営として痛みは感じていても、正確にいくらなのかは誰も把握していない。確かなのは、決して小さくないということです。
そして、この費用は見つかる時期だけで桁が変わります。
- ×1 設計段階で見つける
- ×10 統合テストで見つける
- ×100–1000 現場・量産で見つける
ソフトウェア開発で長く知られた経験則です。装置では、これに現場での再作業・納期遅延・安全認証の再提出が重なります。
なぜ、いま
それを防いできたのは、結局のところ人でした。
これまでこうした欠陥を食い止めてきたのは、長くやってきた熟練の方の勘です。設計を見た瞬間に「これは危ない」と分かる、あの感覚です。
その方々が退職されています。そして、代わりの若い技術者は年々採りにくくなっている。問題は変わらないのに、防いでいた網だけが薄くなっている——時間が経つほど、この差は開いていきます。
私たちがすること
人を増やさずに、その仕事を引き受けます。
装置をつくる前に、設計のなかに隠れている欠陥を探してお返しします。人が思いつかなかった状況まで含めて、その装置が置かれうる場合をひとつ残らず調べ尽くして見つけ出します。
熟練の方をもうひとり迎えるかわりに、その役割を私たちが担う、とお考えください。
お受け取りいただくもの
その欠陥が、どんな順番で起きるか
「どこかがおかしい」ではなく、その不具合が起きるまでの正確な手順そのものです。
危険な状態は「起こらない」という証明
起きなかった、ではありません。確かめた範囲において、この設計では起こり得ない、という確認です。範囲は着手前にご相談のうえ決めます。
いずれも、担当の方が次の設計会議にそのまま持ち込める形でお渡しします。読み解きの要る報告書ではなく、すぐ使える結果です。
御社の技術について
御社の図面は、会社の外に一歩も出ません。
私たちのプログラムは御社のなかだけで動きます。外部へデータを送りません。近ごろよくある、図面を AI に読み込ませる方式でもありません。
自分の技術を守る会社が、お客様の技術も守ります。
実証済みの方法です
私たちが考え出したやり方ではありません。
「そんなことが本当にできるのか」と思われるはずです。もっともなご懸念です。
これは私たちの発明ではありません。世界で最も高い水準を求められる企業が、すでに長くこの方法を使っています。航空や鉄道の安全認証にいたっては、この方法を要求しています。私たちがするのは、すでに検証の済んだ方法を御社の現場に合う形に持ち込むことだけです。
ご提案
大きく始める必要はありません。設計ひとつ、お預けください。
いちばん実物に近い電装設計をひとつ、お預けいただければ十分です。秘密保持契約を結んだうえで進め、結果をご覧になってから次をご判断ください。
言葉で説得はいたしません。御社の実際の設計ひとつで、結果としてお見せします。
- 対象
- 御社の設計ひとつ（電装設計を推奨）。範囲は着手前に確定します
- 期間
- 確定した範囲に対して 4〜8週間が目安
- 条件
- NDA 締結。設計文書は非公開として扱います
- 実機
- 不要。設計文書から動作の条件と状態が追えることが前提です
- 費用
- 初回のご協力はレファレンス条件でご負担を抑えます
ここから先は技術的な内容です
設計・検証を担当される方向けに、上の説明を技術の言葉で書き直しています。
社名について
基準（datum）が疑わしければ、その上のすべてが疑わしい。
図面のデータムは、すべての寸法がそこから測られる基準です。データムが疑わしければ、その上に積まれた測定はすべて疑わしくなる —— だから図面は、まず基準を明示することから始まります。
装置ソフトウェアにとっての基準は設計です。しかし装置業界では、その基準そのものは証明されないまま、実装とテストだけが積み上げられてきました。
DatumProof は、その基準を証明可能にする会社です。
課題
V字モデルの右半分が、実行できない
正しい開発プロセス（V字モデル）の左側 —— 要求定義、リスクアセスメント、安全要求仕様、システム設計、詳細設計、実装 —— は、既存の資料と熟練者の経験で実行できます。問題は右側、つまり検証です。
自動化装置には、分離した単位でテストする物理的な構造がありません。その結果、単体テストとモジュール検証が成立せず、検証は統合テスト → システム検証 → 現場検証にのみ依存する。数十年にわたり、業界は「装置が動けば OK」という経験的検証で凌いできました。
この検証の空白の代償は、誤りが最も高くつく瞬間に現れることです。単体テストもモジュール検証もなければ、誤りの箇所を特定できません。現場で問題が出たとき、「設計の問題か、実装の問題か」を判断するところから始めることになります。
私たちの立ち位置
私たちは需要をつくりません。すでにモデルへ向かう流れの上に、一段を載せます。
形式手法は、装置業界にとって唐突な話に見えるかもしれません。しかし実際には、世界はすでに「モデルで設計する」方向へ動いています —— モデルベースシステムズエンジニアリング（MBSE）は、二桁成長の市場です。
モデルをつくることと、そのモデルが正しいと証明することは、別の仕事です。 DatumProof は、モデルをつくる道具（MBSE / MBD）と競合しません。その上に載る検証レイヤーです。
- 01 装置が複雑になり、頭と紙のなかだけでは設計が追いつかなくなった。
- 02 だから世界は「モデル」で設計するようになった（MBSE / MBD）。
- 03 しかし ——「そのモデルは本当に正しいのか」を、誰も証明していない。
- 04 形式手法による検証が、その空白を埋める。 DatumProof
テストとの違い
「やってみたが、起きなかった」と「起こり得ないと証明した」の差
同時実行とタイミングの不具合を、設計段階で見つける
複数の軸・センサ・制御器が同時に動くことで生じる競合状態やデッドラック、タイミング依存の不具合は、発生確率が低くテストでの再現が極めて困難です。テスト中には出ず、現場で出る。設計検証はこれを机上で見つけます。
「試した範囲」ではなく、起こりうるすべての状態を確認する
テストが確かめられるのは「設計者が思いついた場合」だけです。設計検証は、その設計で到達しうるすべての状態について、安全条件が成り立つことを数学的に確認します。
不具合は、再現手順そのものとして返ってくる
「どこかが間違っている」ではありません。その不具合を再現する正確なイベント列 —— 反例（counterexample）—— が得られます。設計レビューにそのまま持ち込める形です。
記事
形式手法を、装置エンジニアの言葉で
形式手法の最大の障壁は、難しさではなく馴染みのなさです。専門家130名への調査では、71.5% が「エンジニアの教育不足」を採用の最大の障壁に挙げました —— 技術そのものへの疑問ではなく。
だから私たちは、売り込みの前に説明を置きます。装置をつくる現場の言葉で、形式手法とは何か、テストと何が違うのか、なぜ安全規格がそれを求めるのかを書いています。
あなたの装置の設計で、確かめてください。
概念ではなく、御社の実際の設計から出た具体的な不具合と反例をお見せします。まずはお話を聞かせてください。