ここではテスト（対象物が正しく動作することを確認する作業）の意味や，これまでソフトウェア工学の世界で議論されてきたテストに関する数々の話題を紹介する．主にソフトウェアの例をもとに解説しているが，多くの議論はHDL設計や回路設計，システム設計におけるテスト（検証）と共通している．テストの問題については，ソフトウェア工学から学ぶべきことが多い．　　（編集部） テスト・チームに送り込まれたのは，不ぐあいとして現れる設計者のミスを見つけるためだった．そんなことがほんとうにできるのかどうか，わからなかった． それはまだ会ったことのない，せっぱ詰まったプロジェクト・リーダの命令だった．プロジェクトにはお金がない．テストの工数は設計ほどまじめに見積もられることはない．スケジュールに対するスラック（余裕時間）に過ぎないのだ． プロトタイプ版の納入に立ち会った．仲間が子どものように走り回る．携帯電話を振り回

クリティカル・システムに使う市販ソフトウェアの検証方法(4) ―― 市販ソフトウェア・ベンダが提供する検証記録の内容 酒井 由夫 本連載では，市販ソフトウェアの使用に際して求められるリスク分析や検証作業，市販ソフトウェアの検証記録の作り方について解説する．今回は，検証記録の提供を受けられる市販ソフトウェアを紹介する．また，米国FDA（食品医薬品局）の要求に対応するOTSソフトウェア・レポートおよび検証記録のサンプルを提示する．（編集部） 技術解説・連載「クリティカル・システムに使う市販ソフトウェアの検証方法」 記事一覧 第1回　ソフトウェア品質論の推移とシステムの安全性確保の考え方 第2回　誰が，何をもって市販ソフトウェアが信頼できることを証明するのか 第3回　検証記録に含めるべき事項を考える 第4回　市販ソフトウェア・ベンダが提供する検証記録の内容 5．市販ソフトウェア検証記録の具体例

自動化し，空いた時間で設計改善 ―― モデリング手法やプロダクト・ライン開発などを社内展開している島 敏博氏に聞く Tech Village編集部 品質保証部としてではなく，設計部の一員として，ソフトウェア開発の改善活動を進めている人物がいる．セイコーエプソン 商業プリンター事業部 商業プリンター企画設計部の島 敏博氏である（写真1）．島氏は，社内の事業所を渡り歩きながら，それぞれの製品開発を改善しているほか，組込みソフトウェア管理者・技術者育成研究会（SESSAME）などの講師も務めている．同氏に，活動の概要と現在に至る経緯，改善活動に取り組む動機などについて伺った． 写真1　セイコーエプソン 商業プリンター事業部 商業プリンター企画設計部の島 敏博氏 ●チームを渡り歩いて内側から品質改善 ―― ふだん，どのような業務を行っていますか． 島氏：組み込み製品向けソフトウェアを開発しています

ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(2) ―― 狙いを定めて投資を回収，ガイドライン策定は必須 大塚 潤 新しい開発手法を取り入れても，定量的な成果が出てこないと推進が難しくなってくる．富士通九州ネットワークテクノロジーズのソフトウェア・プロダクト・ライン開発適用も壁に突き当たりつつあった．そのような中で，比較的規模の大きなプロジェクトにおいて成功事例が生まれた．第2回は，成功事例に至ったファームウェア開発について，プロジェクト・リーダの立場から解説する．（編集部） 技術解説・連載「ソフトウェア・プロダクト・ライン開発手法の実践的導入事例」 バック・ナンバ 第1回　管理者は「石の上にも3世代目」 経営層の協力を取り付け，プロダクト・ライン開発手法を推進してきた筆者たちでしたが，定量的な成果に結びつくプロジェクトがなかなか現れず，手法の有効性には手ごたえを感じつつも，開

組み込みシステムには，厳しいリソース制約やリアルタイム性の確保など，いくつかの特徴があります．そして，これらと並んで重要となるシステム要件が，高い信頼性や安全性，およびセキュリティの確保です．これらをひっくるめて「ディペンダビリティ（Dependability）」と呼びます． 例えば，医療機器や自動車，工作機械などを制御する場合，システムが誤動作を起こすと多大な損害が発生します．ときには人命にかかわるトラブルになる場合もあります．また，家電製品などの民生機器であっても，リコールによって市場出荷後に製品の回収が発生すると，大きな損害が生じます． 組み込みシステムを開発するにあたっては，こうした誤動作の発生を防止したり，誤動作が発生したときの影響を最小限に抑えるための対策を事前に検討しておく必要があります． 組み込みネットでは，組み込みシステムの「高信頼，安心・安全」にかかわる情報として，以下

本コラムでは，AUTOSARの各種ソフトウェア・コンポーネント(SWC)や基本ソフトウェア(BSW)などが標準化され，再利用が可能になることにより，開発効率や品質が向上すること，そしてAUTOSARの一連のフローについて解説しました． 今回は番外編として，AUTOSARを現実の車載システムに適用する際のテクニックとして 複合デバイス・ドライバ（CCD：Complex Device Driver） インプリメンテーション・コンフォーマンス・クラス（ICC：Implementation Conformance Class）の二つを説明します．複合デバイス・ドライバは，主に処理が間に合わない時などに使用します．インプリメンテーション・コンフォーマンス・クラスは，全ての基本ソフトウェアがAUTOSARに準拠していない時などに，準拠の範囲を決めて適用できるようにするために使用します． ●複合デバイス

この連載では，ライティング・スキルの話だけでなく，仕事をうまく進めるための「文書の作り方」として，「文書作成術」を解説してきた．文書の書き方が仕事のやり方に大いに関係していることに気づいていただけただろうか．「そうは言っても，いざ現実の自分の仕事に戻ると，とても文書なんか作っていられない」という方も，まだまだ多いかもしれない．そんな方々の仕事の助けとなることを信じて，ヒントやメッセージを出し続けていきたいと思っている．今回は，最終回として，これまでの内容を総括する．（筆者） 技術解説・連載「理系のための文書作成術」 記事一覧 第1回　開発文書を分かりやすく記述する 第2回　図表を表現手段として活用する 第3回　開発文書の書き方はしごとのやり方を示す 第4回　自分の「赤ペン先生」を持とう 第5回　設計レビューでするべきこと，してはいけないこと 第6回　仕事で文書を「書かされている」あなたへの

組み込み業界と半導体業界の積極的なコラボで新市場の創造を ―― 機器制御のためのAPI「OpenEL」を標準化 中村 憲一 2012年は，エルピーダメモリの破たんに始まり，ルネサスエレクトロニクスの経営再建など，半導体業界にとって非常に厳しい年となっています．また，半導体業界の大口顧客である家電メーカにおいても，ソニー，パナソニック，シャープの業績悪化など，暗いニュースが続いています． これらの原因として，いろいろな分析がありますが，やはりビジネス・モデルが変化してきていることが最大の原因ではないかと思います．モジュール型製品が台頭し，「すり合わせ型の開発」から「組み合わせ型の開発」への変化，つまり垂直統合モデルから水平分業モデルへの変化が背景にあると思います．製品アーキテクチャとそのインターフェースが標準化されたことにより，部品さえ入手できれば誰でも同じような製品が作れるようになりました

「納期に間に合わない」という焦りで失敗しないためには？ ―― 第12回 組込みシステム技術に関するサマーワークショップ（SWEST12） 山本 雅基 2010年9月2日～3日，ホテル日航豊橋（愛知県豊橋市）にて，「第12回 組込みシステム技術に関するサマーワークショップ」（SWEST；Summer Workshop on Embedded System Technologies，エスウェストと発音）が開催された（写真1）． 写真1　第12回 組込みシステム技術に関するサマーワークショップ（SWEST12） 2日のセッションの一つ「ETロボコンから考える組込みエンジニアリング」の様子． SWESTは，「産学の人的交流を促し，産学の双方が組み込みシステムの開発や研究のヒントを得ること」などを目的として，毎年夏に泊まりがけで開催されている．伝統的に，情報処理学会 システムLSI設計技術研究会が主

ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(4) ―― 社内・社外から見た導入のかぎ 岩崎 孝司，内場 誠，中西 恒夫 筆者らが取り組んできたソフトウェア・プロダクト・ライン開発手法の導入事例を3回にわたって紹介してきた．各プロジェクトでの効果はさまざまだったが，いくつかのプロジェクトで具体的かつ定量的な成果が見え始めたことにより，その結果に触発された複数の部門が自ら進んでプロダクト・ライン開発に取り組み始めるという好循環が生まれた．最終回となる今回は，プロダクト・ライン開発手法の導入に成功するためのかぎを，社内および社外の視点から紹介する．（編集部） 技術解説・連載「ソフトウェア・プロダクト・ライン開発手法の実践的導入事例」 バック・ナンバ 第1回　管理者は「石の上にも3世代目」 第2回　狙いを定めて投資を回収，ガイドライン策定は必須 第3回　導入方法と効果は開発タイプごと

ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(3) ―― 導入方法と効果は開発タイプごとに異なる 内場 誠，佃 紀昭 前回は，ソフトウェア・プロダクト・ライン開発手法の適用で大きな成果を挙げた大規模なファームウェア開発の事例について紹介した．なお筆者らの会社では，ファームウェア開発のみならず，ハードウェア開発を含むさまざまな開発にもソフトウェア・プロダクト・ライン開発手法の導入を試みた．今回は，これらの開発に対するソフトウェア・プロダクト・ラインの導入事例を紹介する．また，いずれのプロジェクトにも共通の悩みとなった，フィーチャ・モデルと実装構造の対応付けについて，分析した結果を示す．（編集部） 技術解説・連載「ソフトウェア・プロダクト・ライン開発手法の実践的導入事例」 バック・ナンバ 第1回　管理者は「石の上にも3世代目」 第2回　狙いを定めて投資を回収，ガイドライン策定は必須

『リアルタイムUMLワークショップ』 著者 ブルース・ダグラス 翻訳 鈴木 尚志 出版社: 翔泳社 ISBN-10: 4798121118 ISBN-13: 978-4798121116 448ページ 発売日： 2009年12月3日 価格: 5,800円（税別） Amazonで購入 本書は，「UMLの本は業務系システムの例ばかりで，組み込みシステムの開発者には役に立たない」，そうお嘆きの諸氏には画期的な書籍である，とまずは言っておきましょう． しかし実のところ，この書籍内のプロセスでいう「オブジェクト分析」までは，業務系システムで行うこととさほど違ったことをしているわけではありません．「今までの本は業務系システムの例だから理解できなかった」と思う方は，ぜひこの『リアルタイムUMLワークショップ』にトライしてください．「組み込みシステムの例だから理解できるというわけでもない」ということに気づ

連載第5回目では，仮想機能バス（VFB）上のアプリケーションの動作を確認したシステムについて，実際のECUやネットワーク構成に対応したソフトウェアを生成する手順を示します． ●AUTOSARのメソドロジ概要　AUTOSARでは，仮想機能バスからはじまりECU上で動作するソフトウェアの生成までのメソドロジ（方法論）を定義しています．このメソドロジでは，各フェーズでソフトウェア・コンポーネントや基本ソフトウェア（BSW）のXMLフォーマットのファイルを使用し，最終段階でC言語などの実行形式に変換する方式をとります． ［図１］AUTOSARのメソドロジ概要 図１で示したメソドロジの概要は以下の通りです．

仮想機能バスを用いたアプリケーションの開発検証 ―― 自動車業界に見る組み込みソフト開発効率化の取り組み（4） 兼平 靖夫 本コラムの第2回と第3回でAUTOSARの階層アーキテクチャや仮想機能バスについて解説しました．今回は，仮想機能バス上でアプリケーションがいかに構成されるか，階層アーキテクチャに変換されたあとシミュレーションで検証できるかを見ていきます． ●仮想機能バス上でのアプリケーション検証 仮想機能バスを用いた開発では，ECU構成やネットワークなどを決める前にアプリケーションの検証が行えます．仮想機能バスは，階層アーキテクチャの中ではアプリケーション層と基本ソフトウェアの間にあるランタイム環境に相当します． 仮想機能バス上での開発・検証は以下のステップで行います． １） ソフトウェア・コンポーネントの配置結線 アプリケーションは，通常複数のソフトウェア・コンポーネントにより構成

連載第3回目はこれまでに説明したアーキテクチャのソフトウェアがどうやって現実のECU構成やプロトコルで実現されるか，およびその核となる仮想機能バス（VFB：Virtual Function Bus）について説明します． ●仮想機能バスで複数ECUを制御する AUTOSARは，前回までに説明したようにソフトウェアを階層に分けたアーキテクチャを持ちます．そして，それぞれを標準化したインターフェースでつなぐことにより，その中のソフトウェアのポータビリティ（移植性）を向上させていました．実際にはECUが一つということはないので，ソフトウェアを階層に分けても車への実装は図1のようになります． ［図1］ 複数ECUへの実装（赤線はデータのやり取り） このままでは，機能をどのECUに割り当てるのかを開発者が考える必要があります．AUTOSARでは，複数ECUのソフトウェア開発に対して「仮想機能バス」とい

連載1回目で説明したように，AUTOSARは階層化されたソフトウェア・アーキテクチャをとっています．具体的には，「アプリケーション層（AUTOSARソフトウェア）」，「ランタイム環境（RTE；Runtime Environment）」，「基本ソフトウェア（BSW）」からなります（図1）．これをもう少し詳しく示すと，図2のようになります．今回は，この中身をもう少し詳しく見ていきます． [図1] AUTOSARのアーキテクチャ ［図2］ AUTOSARのアーキテクチャ（詳細） （AUTOSAR Technical Overview V2.2.2 R3.1 Rev.001より引用） ●アプリケーションはECUを知る必要がない 図2の例では，特定のアプリケーションとしてセンサやアクチュエータのアプリケーションなどが接続されています．アプリケーション・コンポーネントは同じAUTOSARランタイム環境

本コラムでは，組み込み業界で注目を集めているわりにはその詳細が知られていない車載ソフトウェアの標準化活動「AUTOSAR（オートザー）」について紹介します． 連載第1回の今回は，AUTOSARの背景や目的，そのアーキテクチャについて説明します． ●主要自動車メーカが参加するコンソーシアム AUTOSARは"The Automotive Open System Architecture"の略であり，自動車製造企業やサプライヤ企業（部品メーカ）を中心につくられたコンソーシアムです．これは2003年7月に設立され，その役割により，コア・パートナ，プレミアム・メンバ，アソシエート・メンバの3種類のメンバで構成されます．コンソーシアム発足当時のプレミアム・メンバはBMW社，Continental社，DaimlerChrysler社，Robert Bosch 社，Siemens VDO Automot

ソフトウェアの「部品化・再利用」は，多くの企業にとって長年の課題になっている．近年，ソフトウェアの部品化・再利用化を加速する開発手法として，ソフトウェア・プロダクト・ラインが注目を集めている．本連載では，富士通九州ネットワークテクノロジーズのソフトウェア・プロダクト・ライン適用事例を紹介する．第1回は，ソフトウェア・プロダクト・ラインの導入の経緯や，ソフトウェア・プロダクト・ラインが定着するまでに解決しなければならなかったさまざまな課題や困難について，導入を推進した管理者の視点から紹介する．（筆者） ●通信システムは派生開発が多く開発期間が長い 　筆者が所属する富士通九州ネットワークテクノロジーズ（以下，富士通QNET）は，富士通の出資によって設立された，通信機器やネットワーク・システムのハードウェア，ソフトウェアを開発する設計開発専門会社です．通信機器は，通信の標準規格に準拠して仕様決定