AUTOSAR勉強2 イベント、リソース、カウンタ
上記の続き。OSオブジェクトの内、イベント、リソース、カウンタについて
2.8 イベント
- イベントはタスクが同期処理を行うためのOSオブジェクトである
2.8.1 イベントとタスクの関係
- イベントは拡張タスクでのみ使用することができる(基本タスクは待ち状態を持たないため)
- イベントは単独のOSオブジェクトではなく、タスクが所有するOSオブジェクトである
2.9 リソース
上限優先度
- リソースは属性として上限優先度を持つ
- リソースの上限優先度は、そのリソースを獲得する全てのタスクの中で最も高いタスク優先度となる優先度である
- C2ISRもそのリソースを獲得する場合は、そのISRの優先度が上限優先度となる
リソースの獲得
- タスクがリソースを獲得した時、OSはタスクの現在優先度を、リソースの上限優先度まで引き上げることで、リソースの上限優先度以下のタスクが実行されることを防止し、共有資源の排他制御を行う。
-マルチコア対応OSにおけるリソース - スケジューリングは各コアで独立して実行するため、コア間でのリソースによる排他制御はできない。コア間での排他制御には、スピンロックを使用する
2.10 カウンタ
- カウンタの接続対象となるOSオブジェクトは、アラームとスケジュールテーブルであり、カウンタによって両者を駆動する
- ティックーカウントする単位。ティックが示すものはアプリケーション依存
2.10.2 カウンタの種別
- ソフトウェアカウンタ
- ティックがOSによって管理され、システムサービスによりティックがインクリメントされるカウンタ
ハードウェアカウンタ
- タイマなどのハードウェアによってティックが管理されるカウンタ
オブジェクトのコア割り付けに関する制約
- アラーム、スケジュールテーブル共に、接続するカウンタは接続対象と同一のコアに割り付けられていなければならない
2.10.5 カウンタの満了処理
- カウンタがインクリメントされ、カウンタに接続するアラームやスケジュールテーブルで指定されたカウント値となった時、カウンタは、アラームやスケジュールテーブルで指定されたアクション(満了処理)を実行する
- カウンタに接続されたアラームやスケジュールテーブルの満了処理は、OS処理レベル(2.2.4処理レベル参照)で動作する
2.10.7 ハードウェアカウンタ
- アラーム、スケジュールテーブルをハードウェアカウンタに接続して使用するには、満了時に起動するC2ISRが必要である
AUTOSAR勉強1
上記を読んで理解した内容を備忘録として残しておく。間違っているかもしれないので、気づいたら修正する予定。
OSオブジェクト
OSの管理するものの単位と認識している。この中にOSAP(複数OSオブジェクトの集合)に所属するもの、コア1に割り付くもの、が存在するので、各々どの分類となるかを残す。
名称 | OSAPに所属するか | コアに割りつくか |
---|---|---|
スケジュールテーブル | ○ | ○ |
カウンタ | ○ | ○ |
イベント | ○ | ○ |
タスク | ○ | ○ |
アラーム | ○ | ○ |
ISR | ○ | ○ |
リソース | ✖️ | ○ |
IOC2 | ✖️ | ○ |
スピンロック | ✖️ | ✖️ |
2.6アプリケーションモード
アプリケーションモード=OSは1つ以上のアプリケーションモードを持つ。ユーザはこれに対応して、OS起動時に自動起動するOSオブジェクトを変更できる。StartOS()の引数としてアプリケーションモードを指定する。
自動起動が可能なOSオブジェクト=タスク、アラーム、スケジュールテーブル
マルチコアOSでは、コア毎に個別のアプリケーションモードを指定することはできない。反した場合、全てのコアで無限ループする。
コア1 | コア2 | 可=○、不可=x | 起動するモードor不可の理由 |
---|---|---|---|
モードA | モードA | ○ | モードAで起動する |
モードA | DONOTCARE | ○ | モードAで起動する |
モードA | モードB | x | モードが異なる |
DONOTCARE | DONOTCARE | x | 1つ以上のコアでモードが指定されていない |
2.7 割り込み処理
- 割り込み処理はスケジューリングポリシーに関係なく、タスクの処理を中断できる。
→割り込み処理は全てのタスクより処理レベルが高い - 割り込み処理はISR IDで区別する。
- コンテナ=複数のコンフィグレーション可能なパラメータで構成されるもの。コンテナはネストする。
2.7.6.4マルチコア対応OSにおける割り込み禁止・許可システムサービス
- 割り込み禁止、許可を行うシステムサービスの対象となる割り込み要因はシステムサービスを呼び出した処理単位が割りついているコアに接続されている割り込み要因のみとする。
=異なるコアから直接、別のコアの割り込み要因の割り込みを禁止、許可できない。
2023/08/23 FP3級の勉強
自分の資産管理、受けられる社会保障制度の把握、人生設計と資格取得を兼ね、FP3級の勉強をしている。
FP3級自体は就職でほぼ役に立たないと言われているが、これらを理解し活用することは、自分の人生を主体的に考え、責任を持つ人になるためには必要であると考えている。
保険・年金・税金とそれぞれの章を勉強してきたが、今勉強している株式等の資産運用の部分がやっぱり面白いと思う。
2023/08/09 自作ゲーム 2作目
2Dシューティング
前回と同様、Unityの勉強を兼ね作成
以下のサイトで遊ぶことができます。
参考にさせていただいたもの
Markdownの練習
普段記事をMarkdown記法で書いているため、Markdown記法の練習ページを残す。
見出し
見出し1
見出し2
見出し3
引用
引用
あああ引用入れ子
リスト
Decimal型
- リスト1
- リスト1-1
- リスト1-2
- リスト2
Disc型
- リスト1
- リスト1-1 入れ子にする場合は、一段につきスペース二つ分入れる
- リスト1-1-1
- リスト1-1 入れ子にする場合は、一段につきスペース二つ分入れる
- リスト2
Definition型
- オレオ
- クッキー&クリーム
- リッツ
- プレーンクラッカー
CheckBox型(使用できない)
- [ ] リスト1
- [x] リスト2
水平線
リンク
https://colagum.hatenablog.com/
インラインリンク
強調
イタリック体
Bold体
イタリック&Bold体
画像
打消し
打消し
アンダーライン
アンダーライン
注釈
注釈付きの文1
コード
$hoge = 1
.md
コードブロック
<div class="radioWave"> <p>```html ```pythonのように種類を指定するとシンタックスハイライトが付く</p> <p>いいいいい</p> </div>
テーブル
Left align | Right align | Center align |
---|---|---|
This | This | This |
column | column | column |
will | will | will |
be | be | be |
left | right | center |
aligned | aligned | aligned |
折り畳み
ここに折りたたんだ時に表示される文字を入れます。
ここに折りたたまれて非表示になっている文字を入れます。
上記以外にも数式等がつかえるらしい。
- ここは注釈です↩
2023/08/01 自作ゲーム
2023/07/30 完全なデレゲーション、そして仕事への取り組み方の振り返り
完全なデレゲーション
「7つの習慣」の中にデレゲーションという言葉が出てきた。日本語にすると「他の人に仕事を任せる事である」。
その中には使い走りのデレゲーションと完全なデレゲーションが存在する。
使い走りのデレゲーションは、「あれをしろ、これをしろ」のように逐一支持を出すものである。仕事の結果の責任は指示を出した者が負う
完全なデレゲーションは、目標とする結果、ガイドライン、使える資源、責任に対する報告、履行(不履行)の結果、を明確にし、指示を出すものである。仕事の結果の責任は、仕事をした者が負う。
勿論、完全なデレゲーションの方が、仕事を任された者の能力が向上し、組織全体の生産性も上がる。
また、上記は指示を出す側の視点で書かれているが、逆を言えば、仕事を引き受ける側になる際には、完全なデレゲーションになるように上司に要求する必要がある。
心に響くものがあったため、完全なデレゲーションの各項目について、引用して記載しておく。
望む結果ー出すべき結果について明確な相互理解を得る。ここでは、「どうやって」より「何を」が大事である。つまり、手段ではなく、結果に焦点を合わせるのだ。この段階で十分に時間をかけることが大切である。望む結果をイメージして、相手にそれを想像してもらい、鮮明に描く。その結果がどう見えるか、またいつ達成されるかを、明確に文章で表現してみる。
ガイドラインー結果を出すにあたり、守らなければならないルールがあれば、それを明確にする。ここでのポイントはガイドラインはなるべく少ない方が良いということである。大きな制約があるならば、それを相手に教えてやるべき手ある。目的を達成するためなら何をやってもいいと相手に感じさせて、長年の決まり事や大切な価値観を壊してしまう結果を招くのは良く無い。そうすることは、逆に相手の率先力を潰してしまう結果となり、再び、「どうすれば良いのか教えてください。そうすれば、その通りにやりますから」と言った指示待ち族のような態度を生み出してしまうからだ。
必ず失敗すると分かっているやり方があるなら、それも明確にしておく。正直に率直に話すことがポイントだ。流砂のある場所や猛獣のいる場所を相手に教えることである。毎日、車輪をゼロの状態から作り直すようなことは避けたい。今まで他人がしてきた失敗から学習できるようにしておくのだ。
しかし、ここでは、失敗するやり方やすべきで無いことは指摘しても、「どのようにしろ」とは言わないことである。結果についての責任はあくまでも任せる相手に取らせるように数る。そのためは、ガイドラインの範囲内で必要な行動が取れるように、環境を整えることが肝要である。使える資源ー望む結果を達成するために、活用できる人的、金銭的、技術的、組織的な資源の範囲を明確にする。
責任に対する報告ー結果を評価するために使われる基準を設定し、評価する人は誰なのか、報告と評価が具体的にいつ行われるかも設定する。
履行(不履行)の結果ー評価の結果によってどうなるか(賞罰)を設定する。これには金銭的な報酬、昇格・昇進、仕事の責任の範囲の拡大、組織のミッション全体と直結した自然の結果などが含まれる。
自分の仕事への取り組みを振り返る
完全なデレゲーションの各項目について、うつ病で休職する前の自分の仕事への取り組み方はどうだったかを振り返る。
望む結果
これに関しては、今の職場に転勤してきてから段々できるようにはなっていた。
明確で無い場合は相互理解を得られるように努めた。
ガイドライン
ここは上手くできていなかったと感じる。
転勤後にプロジェクトの契約形態も変わり、ガイドラインが著しく増えた。
任される仕事固有のものではなくプロジェクト全体として前提となるガイドラインが多く、教育は行われていたが、入ってきたばかりの自分にはきついと感じるものだった。また、周りがこれに準拠し当たり前のように仕事をしているのを見て、これぐらいは当たり前にできなければいけないのかという思いに囚われ、質問して確認することができにくくなっていた。
使える資源
これも明確にできず、仕事を進めてしまい、止まることが多かった。
契約形態が変化したため、「どこまで他の人の時間を使っていいのか」「誰に質問していいのか」が分から無いまま進めてしまっていた。
これについても、ガイドラインと同様、周りがこれに準拠し当たり前のように仕事をしているのを見て、これぐらいは当たり前にできなければいけないのかという思いに囚われ、質問して確認することができにくくなっていた。
責任に対する報告
これはプロジェクトのルールとして明確になっていた。
履行(不履行)の結果
これは明確にしていなかった。仕事をこなせば、勝手に評価されるだろうと思い込んでいた。
振り返りのまとめ
仕事に復帰した際には、仕事を引き受ける際はできていなかった部分を明確にして取り組む。また、自分が人にデレゲーションする時には、各項目を明確にする。