12/15、日立の技術研修所にて、「ソフトウェア・アーキテクトへの道 –アーキテクト自らが語る、今日の自分を形成した学習と経験-」と題した研修の講師をさせていただきました。 今回は、日立情報制御ソリューションズ渡辺滋さんのとってもおもしろい企画です。講師陣は、ビースラッシュの山田大介さん、メタボリックスの山田正樹さん、東海大学の清水尚彦さん、グロースエクスパートナーズの鈴木雄介さん、そして私の5人で、5人が自身の経験とアーキテクトとは何か、を語るという趣向です。 ソフトウェア・アーキテクト、または、ITアーキテクトという職種、称号は、最近、よく話題にのぼります。あるプロジェクトが開発する製品、システムの全体像を把握して、そのソフトウェアの基本設計、方式設計をするプロジェクトの最高技術責任者といった意味で用いられることが多いようです。しかし、実際にアーキテクトの活躍を目の当たりにする機会も
読者の皆様は「分解できないソフトウエア」と聞いて,何を思い浮かべるだろうか。 いろいろな意味に想像する方がいるだろう。「スパゲッティのように絡みあい複雑すぎて,その構造や仕組みがとらえきれない」という風にも解釈できるし,「物理的実体がないので,ハードウエアのようにばらすことができない」という風にもとらえられる。「バイナリ・イメージの逆アセンブルなど,ソフトウエアのリバース・エンジニアリング行為の禁止」を思い浮かべる方もいらっしゃるかもしれない。 日経エレクトロニクスの12/31号では,この「分解できない」という点をモチーフに,組み込みソフトウエア技術者の人材育成や教育に焦点を当てた特集記事を執筆した。タイトルは「かっこいいソフトウエア ――人海戦術より『あこがれ』づくりを」。この場を借りて,少しだけその特集記事の宣伝をさせて頂きたい。 今回の特集記事では,ソフトウエアの「分解できない」とい
組み込み機器向けソフトウエアの規模が指数関数的に増えている。ハードウエアの開発工数を上回るケースも少なくない。特に携帯電話機では,ハードウエア開発の10倍近くをソフトウエア開発に要する。これまでは,家内手工業的な手法によって自転車操業的にソフトウエアを開発することがほとんどだったが,最近はソフトウエア開発に対する意識改革が進み始めた。ソフトウエア規模の増大に対応すべく,先進的なソフトウエア開発方法論を取り入れる先進企業が現れている。「ケータイ」「デジタル家電」「クルマ」などの先進事例を取り上げながら,上流設計から下流のテスト・検証工程に至るまで,組み込みソフトウエア開発の現状を浮き彫りにする。「プラットフォーム型開発」「オープンソース」,「オフショア開発」「モデル・ベース開発」「テスト」そして「理工系離れ」などをキーワードに,パネリストが各現場の工夫点を紹介すると同時に,今後のソフトウエア
DeClang 誕生!Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】DeNA
Thank you for joining us at Microsoft’s Strategic Architect Forum 2015 Session videos and presentations are now available online See sessions, presentations and additional relevant content here Architecture blueprintsScenario-based diagrams that help you build new solutions fastWatch the videoTransform technology to an asset to grow your business and your career<iframe width="980" height="550" all
情報システムの良しあしはアーキテクチャーで決まる――。よく言われることだが、これは正しいのだろうか?正しいとは思うが、どうもふに落ちない。たぶん「アーキテクチャー」が何を指すのかが明確ではないからだと思う。 アーキテクチャーという言葉を聞いたことのないITエンジニアはいないだろう。IT業界だけで使われる言葉ではないが、IT業界では「システム」や「ソフトウエア」といった言葉とくっついて頻繁に使われている。しかし、よく使われる言葉にもかかわらず、それが何かを明確に説明できる人は少ないと思う。 「アーキテクチャーとは、システムやソフトウエアの構造のこと」と説明を受けることがある(他にもいろいろな説明がなされるが、ここでは話を分かりやすくするため「構造」で説明されるケースに絞る)。 ここでいう構造とは、例えば「ハードウエアが何台あってそこにどんなミドルウエアが動いて何の役割を果たすのか」「アプリケ
連載第5回目では,仮想機能バス(VFB)上のアプリケーションの動作を確認したシステムについて,実際のECUやネットワーク構成に対応したソフトウェアを生成する手順を示します. ●AUTOSARのメソドロジ概要 AUTOSARでは,仮想機能バスからはじまりECU上で動作するソフトウェアの生成までのメソドロジ(方法論)を定義しています.このメソドロジでは,各フェーズでソフトウェア・コンポーネントや基本ソフトウェア(BSW)のXMLフォーマットのファイルを使用し,最終段階でC言語などの実行形式に変換する方式をとります. [図1]AUTOSARのメソドロジ概要 図1で示したメソドロジの概要は以下の通りです.
仮想機能バスを用いたアプリケーションの開発検証 ―― 自動車業界に見る組み込みソフト開発効率化の取り組み(4) 兼平 靖夫 本コラムの第2回と第3回でAUTOSARの階層アーキテクチャや仮想機能バスについて解説しました.今回は,仮想機能バス上でアプリケーションがいかに構成されるか,階層アーキテクチャに変換されたあとシミュレーションで検証できるかを見ていきます. ●仮想機能バス上でのアプリケーション検証 仮想機能バスを用いた開発では,ECU構成やネットワークなどを決める前にアプリケーションの検証が行えます.仮想機能バスは,階層アーキテクチャの中ではアプリケーション層と基本ソフトウェアの間にあるランタイム環境に相当します. 仮想機能バス上での開発・検証は以下のステップで行います. 1) ソフトウェア・コンポーネントの配置結線 アプリケーションは,通常複数のソフトウェア・コンポーネントにより構成
連載第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
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "Hardware Abstraction Layer" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL(2020年12月) Hardware Abstraction Layer (HAL、ハードウェア抽象化レイヤー) とは、コンピュータのハードウェアとそのコンピュータ上で動作するソフトウェアの間に存在する、ソフトウェアで実装した抽象化レイヤーである。オペレーティングシステム (OS) のカーネルからハードウェア毎に異なる差異を隠蔽する機能を持ち、それによってカーネルコードは異なるハードウェアのシステム上で動作してもほとんど変更する必要がなく
Important Information for this Arm website This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work. Accept and hide this message The Common Microcontrolle
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く