東京新聞:想像してみてほしい。深刻な食中毒を引き起こしたばかりのレス…:社説・コラム(TOKYO Web)
想像してみてほしい。深刻な食中毒を引き起こしたばかりのレストランの経営者が、同業者の会合で「食品衛生の高い技術を提供する」と言ったら、一体、どう思われるか▼しでかしたのは、はるかに重大な失敗なのだから、野田首相の方が一層、奇異だろう。国連の会合での演説で「原子力利用を模索する国々の関心に応える」と述べ、原発輸出継続の意向を表明した▼脱原発、原発維持のどちら側ともつかず、なるほど“ノーサイド首相”らしくもあった野田さんだが、最近、少し維持サイドに傾く気配。米紙に対しても、定検中の原発について「来年夏に向け再稼働できるものはさせる」と▼地元には、「安全性の確保とか国が責任を持つといった説明」をするというが「絶対安全」などあり得ぬこと、あの原発事故で国民は百も承知。首相はどうやって、その、ないものに「責任を持つ」のか▼無論、「絶対安全」がないのは原発に限らない。風力発電の風車だって絶対脱落しない
「UMLを大規模な組み込みシステムの開発でどのように使うか」という疑問に答える解説書 ―― 『リアルタイムUMLワークショップ』
『リアルタイムUMLワークショップ』 著者 ブルース・ダグラス 翻訳 鈴木 尚志 出版社: 翔泳社 ISBN-10: 4798121118 ISBN-13: 978-4798121116 448ページ 発売日： 2009年12月3日 価格: 5,800円（税別） Amazonで購入 本書は，「UMLの本は業務系システムの例ばかりで，組み込みシステムの開発者には役に立たない」，そうお嘆きの諸氏には画期的な書籍である，とまずは言っておきましょう． しかし実のところ，この書籍内のプロセスでいう「オブジェクト分析」までは，業務系システムで行うこととさほど違ったことをしているわけではありません．「今までの本は業務系システムの例だから理解できなかった」と思う方は，ぜひこの『リアルタイムUMLワークショップ』にトライしてください．「組み込みシステムの例だから理解できるというわけでもない」ということに気づ
自動車業界に見る組み込みソフト開発効率化の取り組み(5) ―― AUTOSARのメソドロジ
連載第5回目では，仮想機能バス（VFB）上のアプリケーションの動作を確認したシステムについて，実際のECUやネットワーク構成に対応したソフトウェアを生成する手順を示します． ●AUTOSARのメソドロジ概要 AUTOSARでは，仮想機能バスからはじまりECU上で動作するソフトウェアの生成までのメソドロジ（方法論）を定義しています．このメソドロジでは，各フェーズでソフトウェア・コンポーネントや基本ソフトウェア（BSW）のXMLフォーマットのファイルを使用し，最終段階でC言語などの実行形式に変換する方式をとります． ［図１］AUTOSARのメソドロジ概要 図１で示したメソドロジの概要は以下の通りです．
仮想機能バスを用いたアプリケーションの開発検証 ―― 自動車業界に見る組み込みソフト開発効率化の取り組み（4）
仮想機能バスを用いたアプリケーションの開発検証 ―― 自動車業界に見る組み込みソフト開発効率化の取り組み（4） 兼平 靖夫 本コラムの第2回と第3回でAUTOSARの階層アーキテクチャや仮想機能バスについて解説しました．今回は，仮想機能バス上でアプリケーションがいかに構成されるか，階層アーキテクチャに変換されたあとシミュレーションで検証できるかを見ていきます． ●仮想機能バス上でのアプリケーション検証 仮想機能バスを用いた開発では，ECU構成やネットワークなどを決める前にアプリケーションの検証が行えます．仮想機能バスは，階層アーキテクチャの中ではアプリケーション層と基本ソフトウェアの間にあるランタイム環境に相当します． 仮想機能バス上での開発・検証は以下のステップで行います． １） ソフトウェア・コンポーネントの配置結線 アプリケーションは，通常複数のソフトウェア・コンポーネントにより構成
AUTOSARの仮想機能バス―― 自動車業界に見る組み込みソフト開発効率化の取り組み（3）
連載第3回目はこれまでに説明したアーキテクチャのソフトウェアがどうやって現実のECU構成やプロトコルで実現されるか，およびその核となる仮想機能バス（VFB：Virtual Function Bus）について説明します． ●仮想機能バスで複数ECUを制御する AUTOSARは，前回までに説明したようにソフトウェアを階層に分けたアーキテクチャを持ちます．そして，それぞれを標準化したインターフェースでつなぐことにより，その中のソフトウェアのポータビリティ（移植性）を向上させていました．実際にはECUが一つということはないので，ソフトウェアを階層に分けても車への実装は図1のようになります． ［図1］ 複数ECUへの実装（赤線はデータのやり取り） このままでは，機能をどのECUに割り当てるのかを開発者が考える必要があります．AUTOSARでは，複数ECUのソフトウェア開発に対して「仮想機能バス」とい
AUTOSARの階層アーキテクチャの詳細 ―― 自動車業界に見る組み込みソフト開発効率化の取り組み（2）
連載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ランタイム環境
定量的なソフトウェア品質管理（pdf)
日科技連とSQiPの取り組み 1980年、日科技連では、日本におけるソフトウェア製品の品質向上と効果的開発の方法論の確立を目指して、「ソフトウェア生産管理研究委員会」（SPC, Software Production Control）を設置しました。 以来、「TQMとソフトウェア工学の結婚」を標榜し、日本的品質管理をソフトウェア生産に適用するための調査・研究・普及を行ってまいりました。 2007年に、この活動が「ソフトウェア品質に関する活動」であると分かりやすくすることと、ソフトウェア技術職という専門的職業の矜持を大事にしたいという思いから、SQiP(Software Quality Profession)に改称しました。 1980年の設立当初は、メインフレーマーで培われたソフトウェア品質技術・施策を議論する場でしたが、現在はソフトウェア産業に関わるすべての方々が議論できる場になっています
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
