2020-07-07

組込みソフト開発とクラウドソフト開発の違い

30年近く組込みソフトウェア開発に携わってきたが、ここに来てクラウドソフトウェアサービスの開発に関わっている。

そこでだいぶ様子が違うことが分かってきた。今回はその違いについて書いてみたい。

IoT機器(組込みソフトウェア機器)を無線/有線ネットワークでクラウドに接続し、クラウドアプリケーションソフトウェアでサービスを提供するというスタイルが増えつつある。

かつて、組込みソフトウェアは出荷時のソフトウェア品質を担保するためウォーターフォール的な開発プロセスが取られてきたが、ソフトウェアの規模が増大するにつれて、組込みソフトウェアでも一部または全体にアジャイル的なプロセスが適用されるようになった。

一方で、クラウドアプケーションソフトウェアの開発はどうだろう。クラウドアプリケーションソフトウェアの開発は DevOps だと言われる。

DevOps については、『DevOpsとは何か? そのツールと組織文化、アジャイルとの違い』の解説がわかりやすい。
DevOpsとは「開発チーム(Development)と運用チーム(Operations)がお互いに協調し合うことで(図1参照)、開発・運用するソフトウェア/システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」という概念である。
【引用おわり】

ようするに、開発しながら運用も行うという、組込みソフトウェアを長年やってきたエンジニアとしては、ちょっと衝撃的な開発スタイルだ。

これが実現可能となっているのは、クラウドサービス提供各社(Microsoft Azure や Amazon AWS等)のクラウドアプリケーションが、クラウド上での各種サービスアプリケーションの組み合わせで、目的を果たせるようになっているところにある。

最終的なUI部分の作り込みは必要だが、IoT機器との接続や、アーカイブ、二次処理、データからのトリガー、セキュリティ確保等々、すでにあるサービスの組み合わせでかなりことができる。

これらのサービスの組み合わせの開発もクラウド上で行うので、クラウドアプリの開発にはPCとインターネットがあれば、それだけでできてしまう。

ただ、クラウドアプリの開発には、各社がクラウドサービスで提供するサービス群を使いこなすためのノウハウ(多くはWEBに情報があるが、使いこなすには経験が必要)をもったエンジニアが必要であり、この主の知識・スキルはかつての組込みソフトエンジニアが持っている知識・スキルとは異なると感じている。

ちなみに、Microsoft は今後のもうけの種をIoT や PC に搭載する Windows OSの販売から、クラウドサービス(Azure)の使用料に大きく舵を切っている。今や、Microsoft Office も Microsoft 365 でクラウドサービスになりつつある。

Microsoft は IoTのOSは Windows にこだわっておらず、Linux でもよいと考えている。だから、最新のWindows 10には WSL(Windows Subsystem for Linux)を追加できるし、Linux から Azure への接続もまったく問題にしていない。

実際やってみてわかるのは、IoTからクラウドへの接続費用とクラウドサービスの使用料はそれなりにかかる。クラウドへの接続のセキュリティレベルを高くしようとすると、それだけ接続料は上がるし、クラウドサービスは使用するサービスの組み合わせでどんどん料金が上がっていく。

エンドユーザは、さまざまなクラウドサービスが無償で提供されている気分になっているが、実際にはかなりのコストがかかっていて、商品の代金やサブスクリプション費用にそのコストが上乗せされている。

商品の価格にクラウドサービスのコストを転嫁すると、商品を売り続けないとダメなので、各企業ともサブスクリプションでエンドユーザからお金をもらいたい。そのためには、Eコマースのサービスを導入する必要があり、その投資も馬鹿にならない。

また、一度、クラウドサービスをエンドユーザに提供し始めると、そう簡単にはやめられなくなる。クラウド業者をスイッチするこは理論的には可能だが、各種提供されるクラウドサービスのインタフェースがまったく同じではないので、実質的には難しい。

よって、クラウドサービス提供業者はクラウドサービスの利用企業を囲い込むことができる。クラウドサービスの提供にはかなりの費用がかかると思うが、それに見合った利益も確保できるので、おいしい商売だと感じる。

さて、DevOps の話にもどると、クラウドサービスでエンドユーザにどんな価値が提供できるのかは、実際やってみないとわからない部分が多い。

また、クラウドへアクセスする部分のUIは比較的簡単に変更可能であるため、ユーザの要望に応じて、運用しながら変更していくこともできる。

そこが、組込みソフトウェアの開発との大きな違いだと感じる。組込みソフトウェアの場合、ネット経由でシステムソフトウェアのアップデートがやりやすくなったとはいえ、リリース時のソフトウェア品質の担保は必須であり、変更にもかなり気を遣うし、検証や妥当性確認の工数も必要だ。

一方でクラウドアプリケーションの場合は、すでに完成されたサービスを組み合わせるため、個々のサービスの信頼性は確保されており、データの流れを変えていくようなイメージで変更ができる。

同じことを組込みソフトウェアで実現することも、ソフトウェアアーキテクチャ次第で可能ではあるが、最初のシステムアーキテクチャの構築が難しい。クラウドアプリケーションの場合は、すでにシステムアーキテクチャが用意されている状態で利用を始めるので、最初の苦労はない。

ちなみに、クラウドアプリケーションで提供される個々のサービスの完成度が高いからといって、試行錯誤的な開発をしていたのでは、エンドユーザの対する品質は担保できない。

アジャイルを単純な試行錯誤的な開発開発スタイルだと思っているエンジニアはさすがに少数になったと思うが、ひょっとして今でもそれなりの数いるのではないかと疑っている。

そういう方には、『アジャイル開発のプロジェクトマネジメントと品質マネジメント: 58のQ&Aで学ぶ』を読むことをお勧めする。

日立製作所でアジャイル開発の品質保証を実践してきた筆者らが、本当の意味での品質を担保したプロのアジャイル開発とは何かについてレクチャーしてくれている。

自分もまだ全部腹に落ちておらず勉強中だが、クラウドアプリケーション開発において実践しないといけないと思っている。

IoT(組込み)ソフトエンジニアとクラウドソフトエンジニア、この二種類のソフトウェアエンジニアが協力しないと、今どきのクラウドサービスが成り立たない。

この二種類のエンジニアは似て非なる者だと思うので、これらの開発をうまくコーディネイトできる人材が成功の鍵となるのではと思っている。

ソフトウェアとハードウェアのつなぎについても、両方の知識や経験をもった技術者(=組込みソフトエンジニア)の存在が重要だったが、IoT と クラウドについても両方の知識・スキルを持ったエンジニアがシステムの全体を俯瞰しながら、適宜最適となるようにソフトウェア開発プロセスを選択的に適用していく必要があるし、二つの文化の違いを理解した上で、それらを上手にマネジメントする必要がある。

明らかに10年前、20年前とは、ソフトウェアの開発スタイルが変わりつつある。クラウドサービスに関しては、クラウドアプリを開発できるエンジニアをどれだけ増やせるかがクラウドサービス提供者の売り上げアップの鍵となるため、クラウドサービスの技術を学ぶための教育コンテンツが驚くほど豊富にWEB上に存在する。それもすべて無償だ。

かつて組込みソフトエンジニアのための教育教材がないということで、SESSAMEが作られたのだが、クラウドエンジニアの教材は豊富に提供されている。このソフトウェアエンジニアのトレーニングという部分での進化もすさまじい。

ただ、勉強することが山ほどあって、分業しないとやってられないという現実はある。だからこそコーディネータの役割は重要だと感じる。

DevOpsを成功させるには、エンドユーザの対する価値と時代による価値の変化を敏感に感じ取るセンスも必要だし、価値をビジネスに結びつけるための戦略を考え、その戦略を実現するための技術が何であるかがわかるようでないとうまくいかない。

組込むソフトウェアとクラウドソフトウェア、新しい時代のソフトウェアエンジニア像について、今後も考えていきたい。

2020-05-15

IoT(組込み系)のソフトウェア技術の e-Learning コンテンツが新型コロナウイルス感染症緊急対策で助成金を利用できます(東京都)

SESSAMEがリリースした 組込みソフトの e-Learning コンテンツについて、東京都が用意した新型コロナウイルス感染症緊急対策で、費用の4/5(上限32万円)の助成申請ができます。

東京都に事業所がある資本金3億円以下、従業員300人以下の企業であれば、新型コロナウイルス感染症緊急対策の中小企業人材オンラインスキルアップ支援助成金を使い、e-Learning 費用の4/5(上限32万円)の助成を申請することができます。

SESSAMEの e-Learning WEBコンテンツは 月額3000円で見放題なので、およそ100名のエンジニアに下記のコンテンツを一か月間 約6万円の費用で受講させることができます。

現在リリースされているタイトル
o.カテゴリ 講義タイトル リリース時期詳細
WB-01初級 プログラミング/テストの基礎 2020年04月
WB-02 構造化分析・設計の基礎 2020年04月
WM-01中級 組込みシステム開発における知的財産権 2020年04月 
WM-02 構成管理(理論編/実践編) 2020年04月
WM-03リアルタイムシステム設計(理論編/実践編)プラットフォーム選定の観点(RTOS編) 2020年04月
WM-04テスト・レビュー・インスペクション 2020年04月

申請期間は第6回の最後が 9月21日なので、申請する企業はお早めに。

------------- SESSAME の e-Learning コンテンツについて ----------

組込みソフトウェア管理者・技術者育成研究会(SESSAMEは) これまで CD-ROM で提供してきた SESSAME e-Learning Series のコンテンツを WEBコンテンツに移行しています。(すべてのコンテンツの移行が完了するまで、CD-ROMでの販売も継続します。) 

今回、初級コンテンツ2講座と中級コンテンツ 5講座を WEBコンテンツ化しました。これまで CD-ROM 1コンテンツ 5000円で、さらに、多人数で視聴する場合は上映権を設定していましたが、WEBコンテンツではひとりのユーザがすべてのリリースコンテンツを 1ヶ月3000円+税で視聴できるようになります。

これにより、短期集中的に組込みソフトウェアを学習したい方、長期に渡り学習したい方の両方にニーズに対応できるようになります。

この機会に是非 SESSAME e-Learning Series (WEBコンテンツ版)をご利用ください。


2020-04-21

『ソフトウェア系国際規格の認証の現状について』の記事に対するコメントと回答

2019-10-20に投稿した『ソフトウェア系国際規格の認証の現状について』の記事に対して2020-02-10にコメントをもらっていて、確認&承認を忘れており、昨日気が付いて承認をしました。2ヶ月以上放置してしまい申し訳ありません。

改めて、コメントの内容をここで紹介し、回答も書きたいと思います。

ーーーーコメント ーーーー

匿名 さんのコメント...
いつも有益な記事をありがとうございます。
汎用ソフトウェアが医療ソフトウェア規格の認証を受けることは意味が無いということは、ソフトウェアを含む医療機器開発には、汎用OSはもちろん、コンパイラが提供するライブラリも使用できないということですね?
リアルいタイムOSはもちろん、Linuxのような巨大なOS相当も、意図する使用を考慮してフルスクラッチが必要であるということですね?もしくは、LinuxクラスのOSは使用してはいけないということですね?
C言語ならいざ知らず、C++やJava 等の言語のメカニズムに相当する部位も汎用ソフトウェアと言えますから、それも使えないということですね?

ーーーーコメントに対する回答 ーーーー

さて、「汎用ソフトウェアが医療ソフトウェア規格の認証を受けることは意味が無いということは、ソフトウェアを含む医療機器開発には、汎用OSはもちろん、コンパイラが提供するライブラリも使用できないということですね?」のご質問に回答します。

汎用ソフトウェア(OTS: Off The Shelf Software)は OTS として検証・評価を行います。IEC 62304 はリスクベースアプローチを採っているため、何に使うのかが定まっていない状態で、リスクベースアプローチのプロセス規格を適用することは意味がないと言っているのであり、医療機器にOTSを使用できないとは一言も言っていません。

米 FDA は 医療機器に使用するOTSに対するガイダンスを発行しており、このガイダンスでは「そのOTSを医療機器に使用したときの懸念レベルを定めて、ハザード分析すること」を医療機器の製造業者に求めています。また、OTSの検証・評価も必要です。これもリスクベースアプローチです。

これについても勘違いしているOTSベンダーが多いのですが、OTSベンダーができるのはOTSの検証(=Verification)の部分であり、OTSが医療機器に使われたときの懸念レベルの推定やハザード分析は、医療機器製造業者が行います。正確には、その OTSを何に使うのか知っている医療機器製造業者しか、懸念レベルの推定やハザード分析はできないということです。

もちろん、Windows や Linux を医療機器に使用することもできますが、それらOTSを医療機器に使用したときのリスクの分析(OTSに障害が起きたときの患者への危害の重大さや発生確率の分析と評価)がもとめらます。

記事の中でも説明したつもりですが、機能安全のアプローチである認証が取れたOTSを使用することを求めるという考え方と、意図する使用(=Intended Use)を明確にした上で、リスクベースアプローチでOTSを使用するという考え方は、元のコンセプトが異なるということです。

リスクベースアプローチの考え方であっても、OTSが使えないということはありません。OTSがどんな用途の医療機器に使用するのかを分析した上で、必要な検証、評価を求めています。

また、コンパイラは 医療機器に組み込まれるソフトウェアではないものの、製品の品質に影響を与えるQMSソフトウェアであることから、そのリスクレベルに応じてバリデーションを求められます。(ISO 13495:2016 より)

さらに、近年の医療機器規制の中のサイバーセキュリティ要求により、汎用ソフトウェアの脆弱性の監視とパッチ対応は医療機器製造業者に対する義務となりつつあります。

いずれにせよ、汎用OSやコンパイラが医療機器に使えないということは一切ありません。

2020-04-18

他業種の医療機器製造業参入について(人工呼吸器そんなに簡単に作れるの?)

新型コロナウイルスの蔓延で人工呼吸器が足らなくなるかもしれないというニュースが駆け巡っている。

それを受けて、自動車やその他の産業から、急遽医療機器の製造を支援したり、医療機器そのものを作りますといった発表も散見される。『ホンダが新型コロナ軽症者の搬送車両を開発、陰圧状態の後部座席で飛沫感染防ぐ』の記事中で、トヨタ自動車の豊田章男社長は、次のように述べている。
人工呼吸器の生産に対しては「人命に直結するモノづくりは簡単ではない」(自工会 会長の豊田章男氏)とし、直接生産は行わない姿勢だ。
それはその通りなのだが、なぜ「人命に直結するモノづくりは簡単ではない」について解説したいと思う。

医療機器は規制が厳しいので、実際にどのような規制要件があるのかを書いてみる。非常時なんだから、一次的に規制は緩和してもいいのではないかという意見もあると思うが、まずは、現状どんな規制があるのかを書く。

法規制

日本では薬機法(旧:薬事法。正式名称:医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律)がある。医療機器としての要件や、医療機器製造業や販売業に関する規定が含まれている。

電気を使用する医療機器では IEC 60601-1 医用電気機器―第1部:基礎安全及び基本性能に関する一般要求事項 の規格に適合しなければならない。

この規格は各種個別規格や副通則もあるので、医療機器の種別によって適合しなければならない規格は複数存在する。

※医療機器には基本要件基準が定められており、IEC 60601-1 は基本要件基準への適合を示すための規格の一つ。

ソフトウェアの要件としては IEC 62304(JIS T 2304)もある。さらに、医療機器を製造するには ISO 13485(ISO 9001 の医療機器版)の認定も必要だ。

どれ一つとってもハードルは高く、そのハードルの高さが、異業種からの医療機器業界への新規参入を阻んでいる。

なぜ、そんなに規制が厳しいのか?

薬機法には公告規制もある。要するに虚偽・誇大広告は法律で禁じられている。
第六十六条 何人も、医薬品、医薬部外品、化粧品、医療機器又は再生医療等製品の名称、製造方法、効能、効果又は性能に関して、明示的であると暗示的であるとを問わず、虚偽又は誇大な記事を広告し、記述し、又は流布してはならない。
効果効能が明確でないのに、「癌が治る」とか「症状が軽減する」などと公告すると、一般市民が惑わされ害があるので規制されている。病気や健康は人々にとって強い関心事であるため、虚偽又は誇大な記事を規制しないとだまされる人が増えて社会が混乱する。

医療機器についても同じで、効能、効果、性能が臨床的に立証されていない機器は売れないし宣伝もできない。

規制がないと、製造業者が表明している機器の機能や性能が実際には十分でなかったり、リスクコントロールがないため事故が起こったりしてしまう。一般的な機器ならユーザがメーカにクレームを言えば済むかもしれないが、医療現場では取り返しがつかないような事態になるかもしれない。だから、医療機器は規制されている。

ベネフィット・リスク分析

多くの薬には副作用がある。副作用があるけれども、効果効能を優先させるために服用が必要な場合もある。例えば、抗がん治療には副作用があるが、延命するためには治療はしなければならない。

医療機器も同様で、リスクはあるがベネフィットが上回るため、ある条件下では使用すべきということが多々ある。

生命維持装置や治療器には大抵リスクがあるので、どんなリスクがあり、それらのリスクを低減してリスクが受容できている状態にしておく必要がある。

そのときに、リスクはあるがベネフィットが上回るので条件付きで使用させるというケースも出てくる。

左図の上部は顕在的な価値、例えばカタログスペックに出てくるような目に見える価値で、下の部分は、表にはでてこないけれど安心や安全を担保する価値になる。当たり前品質とも言える。

医療機器は、この潜在的価値の部分が脆弱だと、人の死に直結してしまう可能性がある。生命維持装置や治療器が期待通りに動かなければ、患者が死亡したり重傷を負ったりするかもしれない。

よって、この潜在的価値の部分を担保するために、さまざまな規制があると言えるし、規制当局は取り締まりをすることで、国民の安全を確保している。

緊急時にそんなこと言ってられない

世の中平温ならいざ知らず、今は、「もたもたしていたら、死者がどんどん増えてしまうではないか」という緊急事態かもしれない。

だから、米FDA(食品医薬品局)は、COVID-19 に関連して、規制を緩和するガイダンスを次々に出してる。例えば、これこれこちらのサイトでCOVID-19をキーワードに検索すると27件ものガイダンスがヒットする。

米国は、FDAにかなりの権限があり、規制に対する裁量権が認められているので、ガイダンスによって規制を緩和することができるようだ。

モバイルアプリに関しても、左図にあるように米国では、医療機器かもしれないが、FDAが執行裁量権を使って取りあえず規制しないというカテゴリーがあるが、日本では、法体系が違うためそのような曖昧なことはできない。

1か0(医療機器か、そうでないか)を判定しないといけない。

よって、現実的には、日本では薬機法を改訂しないかぎり、従来の規制を一次的に緩和することは難しい。

特に、現実問題、医療機器の製造業・販売業の業の認定がない企業に、一次的ではあっても医療機器を製造したり、販売させることはできないだろう。

米国も同じだが、審査の工程を簡素化したり、短縮したりすることはできるようだ。

現実的には何が問題になるのか

法規制のことはいったん横においておいて、実際にこの緊急時に異業種の企業が人工呼吸器を作ることにどんな問題があるのだろうか。

コロナ最前線で戦う医療現場にTeslaが約束の「人工呼吸器」を送ったという記事があった。

ところが、この機器は、睡眠時無呼吸症候群の治療機機器であるCPAPの機器だったようだ。価格は800ドルで、侵襲型の人工呼吸器(約5万ドル)とは異なる。

機能としては、CPAPも人工呼吸器も酸素を送り込むので似ているが、意図する使用/意図する目的(Intended Use)が異なる。

臨床的に目的が異なるものを緊急で転用するならその違いを理解している人が機器を扱わないと事故が起こる危険があるし、人間は必ずミスをする(ヒューマンエラーはなくならない)ので、臨時の使い方を多くの人がするようになると気をつけないといけないことを怠って事故が起こる確率も徐々に上がっていくだろう。

それも含めて緊急事態だからベネフィット・リスクを考えて、臨時的な使い方を許容するという選択肢もあるかもしれない。

どちらを優先させるべきか悩ましいが、前提として臨床的に有効性のない機器を投入することは間違いだと言えるし、患者が死や重傷に至るようなリスクに対してリスクコントロールがされており、リスクが受容できているという確認(=バリデーション)は必ず必要だ。

特に、医療機器の開発にあたっては、臨床的な知識や医療現場での機器の使われ方、治療や診断の実際について、開発者が十分に理解していることが重要だ。

今、集中治療学会は、新型コロナウイルス感染症(COVID-19)の対応に関連して、人工呼吸教育ビデオや、新型コロナウイルス肺炎患者に使用する人工呼吸器等の取り扱いについて(Ver.2.0)などの情報を公開している。

これを見るだけでも人工呼吸器は取り扱いに注意が必要で、十分なメインテナンスが必要な機器であることがわかる。

「人工呼吸器の部品を3Dプリンタで作りました」などのニュースを見ると、作った部品は滅菌できるのかとか、つなぎ目から空気の漏れは起こらないのか、薬液耐性は大丈夫かとかといった疑問が沸く。

人工呼吸器を本気で作ろうと考えている設計者は、まずは、臨床的な知識、治療の実際について理解してから、自分達が持っている技術がどの部分に活かせるのかを考える必要があると思う。

総合的な感想

現在の医療機器規制は過去の事故の再発防止策などが積み重なって今に至っている。ただし、改めてそれらができていないと安全ではないのか、逆にそれらができていれば安全なのかという疑問がないわけではない。

例えば、IEC 62304 はプロセス規格なので、この規格への適合と機器の安全は一体一ではない。機器としてのリスクを分析しており、リスクが受容できていることの確認はしている。でも、この規格の一つ一つの要求について、本当に必要か?という要求もないわけではない。

再発防止策の積み重ねは40年以上続いているのでハードルはどんどん高くなっており、医療機器ドメインへの新規参入はかなり難しくなっている。

でもハードルを下げれば、事故は増えるだろう。だからこそ、リスクの高い機器についてはハードルを上げざるを得ず、リスクの低い機器やヘルスソフトウェアのハードルは下げて上げるのが現実的であり、米FDAはそういうアプローチを採っている。

では、人工呼吸器はどうか。生命維持装置なのでリスクが高い機器であることは間違いない。人工呼吸器が足らない状況にみんなが協力して打開しようとすることはとても良いことだが、よかれと思った取った行動が逆の結果を招くかもしれないのが、医療機器の怖さでもある。

意図通りに動作すれば社会に貢献でき、高い満足感も得られるが、その裏側には大きな責任(=リスク回避の責任)もあるということだ。

この危機的な状況にあっても、安易に実験的な機器を現場に投入するよりは、現存する機器の増産の可能性を探ることが現実的なような気がする。

日本の自動車業界が医療機器製造業者に製造に関する支援を表明しているのはそういう理屈なのだろう。

2020-04-09

Raspberry Pi3を使ったリアル波形描画(10) アーキテクチャの設計思想について(2)

本特集記事の「Raspberry Pi3を使ったリアル波形描画」を実現するにあたり、採用したアーキテクチャの設計思想を説明しようと思う。前回は、全体のシステムの中の入力部分の説明をした。

今回は、このシステムの重要な要素(=商品価値=コアコンピタンスとなりうる部分)の説明をする。

アイテム構成にうち、他社に真似できない商品価値となる部分(コアコンピタンス)のソフトウェアを再利用可能な資産にすることができれば、商品の価値となるソフトウェアアイテムをベースに派生製品を作ることができる。それらの商品群は個々の商品の競合力が高く、かつ、商品群としても強く、さらに、効率よく派生開発が可能となる。

コア資産部分がUIやI/Fに依存していなければ、コア資産をベースにさまざまなI/FやUIを持った派生製品を作ることができる。汎用I/Fや、UIは時代とともにどんどん代わっていくので、それらに対応していき、コア資産の実力をじっくりと高めていけば、商品群は競争力を高いまま維持することができるはずだ。

コア資産が他社の追随を許さない性能を持っている、または特許で知財が保護されていれば、競合しても勝つことができるし、仮に営業力で負けても、長いこと使っていればユーザのその性能の差に気が付き、戻ってくるだろう。

本システムは、基本的には、心電図を入力し、デジタルフィルタで波形を整えて、心電図のQRS(ピンと上に跳ねる部分)を検出して、心拍数を算出し、その結果や波形や付帯情報をディスプレイに表示します。

先の一番下のレイヤーがデータソースレイヤーで心電図の入力部、真ん中がドメインレイヤーで、デジタルフィルタや心拍数計測部、一番上がプレゼンテーションレイヤーで結果を表示する部分です。

今回は、重要な不整脈の解析などは入れていませんが、それがあればドメインレイヤーに含まれ、解析性能が良ければコアコンピタンスになります。

ちなみに、デジタルフィルターやQRS検出の部分も、それなりにノウハウがあるはずなので、コアコンピタンスになります。

左記の緑のクラスがそれに相当します。

EcgAcLineNoiseFilter クラスは、心電図に重畳する50Hzや60Hzの電源ノイズを除去するフィルターで、EcgDriftFreeFilter クラスは、呼吸やその他の基線変動要因を取り除き、心電図を見やすくし、心拍数計測の精度を高めるために必要なアイテムです。
EcgHighCutFilter はアナログフィルターで取り除いてもなお、残っている40Hzより高域のノイズ成分を取り除くフィルターとなります。QrsDetectorTypeTest1 クラスは、心電図のQRSを検出するためのクラスで、このシステムの中ではもっとも複雑性が高く、システムの性能に寄与するアイテムです。TypeTest1としているのは、QRS検出のソフトウェアは試行錯誤しながら精度を高めていくことが多く、1回で完成することはなく、いろいろな試行を繰り返すことになるからです。

このクラス図では、派生クラスにしていませんが、インタフェースを共通にしておいて派生させていろいろなタイプを作って差し替えながら、性能を検証していくのがよいと思います。

また、デジタルフィルタについても、一度固まってしまえば変更することはあまりないと思いますが、こちらもベースクラスから派生させておいて、後々差し替えられるようにするのもよいと思います。

実際、デジタルフィルタは C言語で数行で表現できてしまうケースもあるため、技術者研修ではわざわざクラスに分けたり、派生させたりしないことが多いようですが、商品としてまた、コアコンピタンスとしてデジタルフィルタを位置づけるのであれば、ソフトウェア資産として独立させて、再利用することに意味があります。

そのソフトウェアシステムのうち、競争力を生み出すコア資産が何か、そのコア資産が再利用しやすくできているか、そこができているかどうかが、競争力の高い商品でかつ、効率のよい開発ができるかどうかの分岐点になります。

詳しくは、『リアルタイムOSから出発して 組込みソフトエンジニアを極める[改装版]』の第三章をお読みください。