設計を、つくる前に検証する。

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

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

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

対象

開発中のシステム、または導入検討中の部品ひとつ。検証する範囲は、着手前の擦り合わせで確定します

期間

確定した範囲に対して 4〜8週間が目安です。範囲が大きい場合は、分割してご提案します

条件

NDA 締結。設計文書は非公開として扱います

費用

対象の規模により個別見積り

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

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

副次的な効果

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

形式手法は新しい主張ではありません。主要な安全規格は、最高位の安全等級において、すでに形式手法を要求または推奨しています。

リスクアセスメントで洗い出した危険シナリオを、モデル化した範囲において「構造的に到達不可能」と証明し、その証明と根拠を、認証審査に提出する資料として使える形に整えます。認証が迫っている場合、検証そのものよりこの文書のほうが急ぐことがあります。

提出資料の作成をお引き受けするもので、認証の可否そのものを保証するものではありません。どの規格のどの要求が御社の装置に適用されるかは、安全等級と用途によって変わります。その判断は、認証機関または御社の安全担当と併せて確認します。

形式手法が普及しない理由は、技術への疑問ではありません。専門家130名への調査では、71.5% が「エンジニアの教育不足」を最大の障壁に挙げました。つまり、必要なのは説得ではなく説明です。

カリキュラムの背骨は「モデルから検証への一段」です。ゼロから教える必要はありません —— 装置エンジニアがすでに知っているモデルベース開発の上に、「そのモデルが正しいと証明する」という一段を載せるところから始めます。

形式

社内向けワークショップ、技術セミナー、設計レビューへの同席。御社の装置を題材にすることも、一般化した例題で始めることもできます。

まず何が書かれているかを読んでから判断したい場合は、記事を公開しています。