１
OSEKは、自動車用OSを定める団体で、VDXとともに作成した仕様を国際規格にしている。国際規格にする直前の版をＷＥＢで公開している。
活動は終了しており、しばしば公式サイトはリンク切れになっていたり、Specificationのサイトがリンク切れになっている。
https://www.osek-vdx.org/
OIL
https://www.osek-vdx.org/mirror/oil23.pdf
この仕様で特徴的なのは、IBMが入っていること。
AUTOSARのToolWGでも、IBMが積極的に活動していた。
BMWなどがIBMのDoorsを使っており、顧客にもDoorsの形式でデータを渡していた。
IMH,IIITはお付き合いの記憶がない。
IMH
https://www.imh-uk.com/sectors/automotive/
IIIT, Uni Karlsruhe
https://www.iiit.kit.edu/
AUTOSARでは、ＯＳは全面採用、ＣＯＭ、ＮＭは一部採用、ＯＩＬ、Ｍｏｄｉｓｔａｒｋは全面不採用。
ＯＩＬは、ＡＲＸＭＬ、ＭｏｄｉｓｔａｒｋはＴｅｓｔ仕様になっている。
ＡＵＴＯＳＡＲ Ｔｅｓｔ仕様は、その後開発を中断している。
OILは、2000年頃の流行りのXMLのような共通の仕組みではない。
AUTOSARを始める原動力のN番目くらいの理由かも。今となっては、C言語風でJson形式とも近く、OILがNowいかも。
当時は、Open OfficeとMicrisoft OfficeがXML規格で競っており、どちらも国際規格になることで、折り合いがついたことがあります。
世の中の半分くらいの仕様がXMLへとなびいている時代でした。
AUTOSARを始める原動力の１番目
Matlab/Simulinkの保守期間が５年くらいで、１０年保守しつづける車の場合には、途中で仕様が変わるのが困る。トヨタ自動車とデンソーは、８年保守というのを結んで維持してもらおうとしたことがある。現在は、断念して、バージョンが変わっても、困らないような情報提供を受ける契約に代わっている。
AUTOSARを始める原動力の２番目
Ethernet, Unix（Linux,Posix）のようなRPCを簡単に実現したいが、OSEK COMの機能だとうまく作れるツールベンダがいなかったのか、方針がいろいろぶれたのか。
AUTOSARを始める原動力の３番目は、RPCを含めて、OSの機能を知らなくてもアプリが作れるようになる。上記のOILは、OSの機能を知っている人が使う道具でうれしくない。
AUTOSARのRunnable関数をConfiguration Editor のAdd taskmappingで一気に割り当てるだけで、後は順番をいれかえればいいのは楽。タスクの切り替え時間、タスクスタックの領域が節約できるかも。
OSEK
https://www.irisa.fr/alf/downloads/puaut/TPNXT/images/os223.pdf
この仕様のオープンソース
https://www.toppers.jp/atk1-download.html
トヨタ自動車が、豊通エレ（現在のNexty）、名古屋大学を通じて、ヴィッツに開発依頼があったOS.翌年度は、経済産業省の補助事業として国のお金で開発。前職で、
この時、Modistarcにも対応しています。
Modistarkの仕様が、現在
OSEK/VDX Conformance Testing Methodology Version 2.0
OSEK/VDX Operating System Test Plan Version 2.0
https://www.osek-vdx.org/portal_subdomain/files/pdf/modistarc/ostestplan20.pdf
OSEK/VDX Operating System Test Procedure Version 2.0
https://www.osek-vdx.org/portal_subdomain/files/pdf/modistarc/ostestproc20.pdf
OSEK/VDX Communication Test Plan Version 2.0
OSEK/VDX Communication Test Procedure Version 2.0
OSEK/VDX Communication Test Suites Version 2.0
OSEK/VDX Network Management Test Plan Version 2.0
OSEK/VDX Network Management Test Procedure Version 2.0
OSEK/VDX direct Network Management Test Suites Version 2.0
OSEK/VDX indirect Network Management Test Suites Version 2.0
のうち、２つしか閲覧できない状況です。
関係者に一度確認してみます。
当時ダウンロードしていたはず。
Modistarkは、主にヴィッツが担当した。公開していない。
特に問題となるエラーがなく、Reviewをほとんどした記憶がない。
２
OSEKTimeOSは、Flexrayのような時分割通信方式を提供するのによいのではないかとの発想で提案。
実際の時分割通信方式は、通信方式自体で時間を管理する機能があることがあり、OSの手助けはいらないことがあるかも。
https://swest.toppers.jp/SWEST8/report/poster.html
「オープンソースFlexRay通信：Time Triggered OS(TT-OS)と
FlexRay通信ミドルウェアの開発
安田友巳，中島浩貴，片岡歩，杉山歩，後藤孝一，
大西秀一，森川聡久，水野智仁，谷川まり子，沼田亜美，
小川貴章，渡邉友裕，橋本昌伸，鵜飼敬幸，服部博行（ヴィッツ）
近年の自動車制御は，搭載するコンピュータの増加，情報処理の複雑化，ネットワークの高負荷時における情報遅延が問題となっており，FlexRay通信に注目が集まっている。今回はTime Triggered OS(TT-OS)とFlexRay通信ミドルウェアの開発を行った。TT-OSはOSEKtimeを元に，タイムトリガタスクとOSEKのタスクの優先度を同じにし，それらを共存させた。展示物は，「ハンドル→（FlexRay）→ラジコン」といった接続がされているデモ機で，実際の動作を確認することができた。」
上記TT-OSはオープンソースでは公開されていない。
https://www.cqpub.co.jp/dwm//contents/0103/dwm010301070.pdf
３
適合クラスのうち、BCC1,ECC1は、タスクをReady Queueで管理せずに配列で管理することもできるような発想。
ECC1は、Eventがあったらすぐに始められるようにする仕組み。ECC2でも、あるPriorityに、１つのタスクだけ割り当てれば同じことができる。
BCC１だけの製品例
https://sunnygiken.jp/product/ciory/
いくつかのシステムでは、BCC1, BCC2, ECC1, ECC2で同じReady Queueを使う場合があります。別々の設計にすると、それぞれ別に試験が必要となるためです。すべての仕様を一つの設計で動かせば、試験を別々にする必要がありません。
補足：スタンレー電気の研修では、OSEKとTRONとの関係の質問がありました。
ITRONの自動車用プロファイルが、ECC2、最小セットプロファイルが、BCC1に対応したものであり、
自動車用プロファイルは、トヨタ自動車と名古屋大学とのなんらかの研究で仕様化されたとお聞きしています。
プロジェクトXで、トヨタ自動車が自動車用プロファイルを利用したおいう話が、いつ放送されたか調査中です。
最小セットプロファイルは、名古屋市工業研究所とヴィッツを退職した技術者で作成し公開しています。
小川清が担当したのは、MISRA-C対応および品質管理です。
このときに、チケットを切りすぎて１００個くらい上げたIssueが１０個も解決しないというやらかしています。
ソースコードで確認する事項
１ Basic Taskだけで、同じ優先度に一つしかタスクを割り当てないプロジェクトを作りソースコードを生成する。
２ 上記プロジェクトのBasic taskのうち一つを別のタスクと同じ優先度に割り当ててソースコードを生成する。
２つのソースコードの違いが、BCC1とBCC2の違いとして認識できるコードがあるかどうか。
３ １のプロジェクトの一つのタスクにイベント街を追加して、ソースコードを生成する。
１と３の２つのソースコードの違いに、BCC1とECC1の違いとして認識できるコードがあるかどうか。
４ ３のプロジェクトのもう一つのタスクにもイベント待ちを追加して、もう一つの拡張タスクと同じ優先度にする。
３と４の２つのソースコードの違いに、ECC1とECC2の違いとして認識できるコードがあるかどうか。
Figure 4-5がReady Queue。
BCC1、ECC1は、横向きにバッファを持つ可能性がある。
ただし、FIFOではない。横向きのバッファは、Queueと言わない方がいいかもしれない。
-----質疑
vector製品でOILという用語がでてくる場合は、
OSEK仕様で作ったものからの移行の場合に、OILをそのまま使い続ける可能性がある。
-----未確認
VectorのOSEK OSの製品のURL
ーーーー
先月の研修で疑問点が出ているのは、Figure3-3
Multiple requesting of task activationで、ECC2がETがNoになっていることの意味。
なんでYesじゃないの？Noってどういうこと？
------ 余談
Number of tasks which are not in the suspended stateがBCC1、BCC2では８になっている。
上記TOPPERSのSSPでは１６で設計。理由は利用者が８じゃ小さいという人が一人いたから。全体を小さくするには８に直せばいい。
OSEK OSの大事な点
１ CAT1というWithou OS ISRとCAT2というWithOS ISRがある。Without OS ISRは、直接OSの機能を呼べないが、WithOSISRを呼べば、間接的にOSの機能が呼べ、できないことがない。
２ Priority Ceiling Protocol
参考資料
Operating Systems OSEK/VDX and AUTOSAR
https://academy.vector.com/jp/en/courses/detail/agenda/3265/operating-systems-osek-vdx-and-autosar.pdf
Driver In the Loop Simulatorを開発している会社が、大量のYoutube動画を挙げている。
https://www.youtube.com/@vigrade01/videos
（前職で）九州大学で導入しているDriver In the Loop Simulatorについて、１０年ほど前学会の研究会で見学し、当時の現状と課題をお聞きし、少し触った。
（前職で）別の学会では、トヨタ自動車が導入しているDrive In the Loop Simulatorの試験の流れにおいての利用方法の説明を受けたことがあるが、実際には触っていない。
（前職で）８年くらい前にDriver In the Loopシミュレータの開発会社が、名古屋地区のOEM、Suppliyerに売り込みへの協力をしたことがある。URLは未確認ー＞
【VR実感型リアルドライブシミュレーションシステム】 T3R VR 株式会社アイロック
https://www.t3rs.net/
HILSからいきなりテストコースでのテストだと、テストドライバの死亡事故を防ぐのは困難。テストドライバの方が利用しても意味のあるDriver In the Loop Simulatorだと、実車開発競争で勝てる可能性がある。
AUTOSARのモジュール類がDriver In the Loop Simulatorで有効なTimingで間に合うのが過去の記憶。
MESW姫路で、100マイクロ秒以下のSimulationがしたいという質問があったことがある。本人以外に、モデルの書き方の方が問題かもと助言したことがある。モデルを書いている人が、ソフトウェア技術者に、モデルのできが悪い可能性を検討せずに、ソフトウェアの仕様として示すことがあるかもしれない。詳細は未確認。
https://www.osek-vdx.org/portal_subdomain/index_option_com_content_task_view_id_15_Itemid_18.html
OSEK/VDX Conformance Testing Methodology Version 2.0
OSEK/VDX Operating System Test Plan Version 2.0
OSEK/VDX Operating System Test Procedure Version 2.0
OSEK/VDX Communication Test Plan Version 2.0
OSEK/VDX Communication Test Procedure Version 2.0
OSEK/VDX Communication Test Suites Version 2.0
OSEK/VDX Network Management Test Plan Version 2.0
OSEK/VDX Network Management Test Procedure Version 2.0
OSEK/VDX direct Network Management Test Suites Version 2.0
OSEK/VDX indirect Network Management Test Suites Version 2.0
MODISTARC is an ESPRIT project
Esprit, the information technologies (IT) programme, is an integrated programme of industrial R&D projects and technology take-up measures. It is managed by DGIII, the Directorate General for Industry of the European Commission.
Objectives and results
The main goal of the MODISTARC project is to support the effort of the European car industry towards the development and standardisation of networking architectures. Through the OSEK/VDX consortium activities, the European industry has issued three new standards defining respectively the OSEK/VDX Operating System, Communication and Network Management. These specifications describe the applicable services and protocols and define the associated APIs. They intend to fulfil the two major goals of the OSEK/VDX initiative:
- enable portability of applications to ECUs coming from different suppliers
- enable interoperability of interconnected ECUs in a distributed automotive system
- enable interoperability of interconnected ECUs in a distributed automotive system
The MODISTARC project aims to help the European car industry to keep its leading position in the network based car architectures by providing the relevant test methods and tools to assess the conformance of OSEK/VDX implementations. To achieve these objectives, the following steps have been defined:
Conformance testing methodology:
The MODISTARC partners intend to develop a conformance testing methodology adapted to the constraints of the automotive environment. A document has been issued under the responsibility of Thomson-CSF Detexis and Forschungszentrum Informatik Karlsruhe (FZI) as a conclusion of the discussions. It serves as the basis for the development of the test specifications and test tools. It is made available as an OSEK/VDX technical document. The main results will be largely advertised through publications and conferences.
Test suites specifications:
The OSEK/VDX test suites version 1.0 and version 2.0 are specified in order to allow the development of conformance tools. The specifications have been issued by FZI for the OS and by Thomson-CSF Detexis for the Communication and Network Management, with assistance of the other partners. These documents become an OSEK/VDX standard since the end of the project. Their ownership has been transferred to the OSEK/VDX consortium. They are publicly available and free of charge on the OSEK/VDX server.
Certification tools:
Certification tools implementing the OSEK/VDX test suites have been developed. They are able to assess conformance of both OSEK/VDX independent software and ECU embedded software after appropriate customisation. Certification tools have been developed by FZI for the OS and by Thomson-CSF Detexis for the Communication and Network Management. They will be marketed and proposed to every company or organisation wishing to produce its own OSEK/VDX implementation.
OSEK/VDX implementations:
In order to validate the certification tools against actual OSEK/VDX implementations, some project partners have adapted or completed their existing implementations to make them compliant with the versions 2.0 of the specifications. Motorola does the work on their PC software. Sagem, Siemens AG and Siemens Automotive build ECU prototypes based on the layered networking architecture defined by the OSEK/VDX consortium. These prototypes will be representatives of the future products the companies plan to market.
Tool demonstration:
A comprehensive demonstration is undertaken to show the relevance of the applied conformance methodology and to validate the certification tools. Firstly, each company having produced an OSEK/VDX implementation will assesses its conformance using the certification tools. PSA has assessed the test suites relevance and completeness on a test platform interconnecting OSEK/VDX prototypes. Interoperability of OSEK/VDX implementations and portability of PSA’s test application on the various prototypes are demonstrated. A report on the demonstration will be widely broadcasted.
Relations to the OSEK/VDX consortium:
The work on the MODISTARC project has been done in close co-operation with the OSEK/VDX consortium. Most technical decisions have been taken during joint meetings with the OSEK/VDX certification group. The IIIT (Institute of Industrial Information Technology) at the University of Karlsruhe has been in charge of reporting project progress to the OSEK/VDX organisation and conversely has brought information and feedback from all other working groups to MODISTARC. Furthermore, both organisations intend to jointly participate in the promotion of the standards and tools produced by MODISTARC. This may concern the car industry or other sectors of activity inside and outside Europe.
Final Public Report on MODISTARC project:
As part of the MODISTARC project, a final public report has been compiled, shortly describing the role of the respective partners within the MODISTARC project. Each company or institution is responsable for their respective section or contribution to this document. The final public report is publicly available.