エンジン エンジン制御概要
自身でmatlab/simulink等を使ってECU設計/検証/シミュレーションの業務を行っていると言い張っているが、実際にECUがどのような目的でどのような制御を行っているかまで把握していることは少ない。
接続されているデバイスと故障診断希(スキャンツール)を起点にして知識掘り下げを行い、知見拡大を狙う。
KEI
エンジン 
S3 AmazonS3 RESTパケット解析(Upload)
今回は、AmazonS3へのUpload。
FTP のPUT相当
AWSのPUT object仕様になる。
aws s3 cp ./command.txt s3://XXXXXXXXXXXXXXX/folder/command.txt
POSTメソッド かと思いきやPUTメソッド らしい。
S3 AmazonS3 RESTパケット解析(Downlaod)
今回は、AmazonS3からのDownload。
FTP のGET相当となる。
S3 仕様としてはGET object に相当。
aws s3 cp s3://XXXXXXXXXXXXXXX/folder/text2.txt ./
HTTPの仕様としてpartial contentsという仕様がある。
SEO 「Google search consoleからの苦情」対策集
「Google search console」から定期的に「XXXXで問題が検出されました」とメールが来ることがある。
それの対処集。
「記事を投稿したら、Google search consoleの"公開URLテスト"を掛けましょう。」
が結論となる。
少なくとも投稿ページの健全性だけでもキープ出来ていると問題の切り分けがしやすくなる。
S3 AmazonS3 RESTパケット解析(リスト取得 max-key付き)
前回、AmazonS3に対してリスト取得のパケットキャプチャを実施した。 しかし、GET Bucket のレスポンス長はディレクトリのファイル数に依存し、必要メモリサイズが予測できないことが多い。 特にIoT 関連デバイス含めた組込み系システムに於いて、必要メモリサイズ不明は死活問題になる。
SEO Google search consoleからの苦情「構文にエラーがある構造化データが検出されました。」
Google search consoleから「構文にエラーがある構造化データが検出されました。文字列中に無効なエスケープシーケンスがあります」と苦情が来た。
何を言っているのかわからん。
「クリック可能な要素同士が近すぎます。テキストが小さすぎて読めません。」の対策と同一。
各投稿編集の「メタディスクリプション」に"￥"抜きな文字列を入れることで回避できる。
S3 AmazonS3 RESTパケット解析(リスト取得)
AmazonS3のBucket内のリスト取得をキャプチャ。
以下のコマンドで発行 aws s3 ls s3://XXXXXXXXXXXXXXX/folder
AWS署名処理にはアルファベット順にソートされている必要がある。
このルールを知らないと「SignatureDoesNotMatch」とだけ言われて、何が間違っているのかよくわからない事態に。
S3 AmazonS3 RESTパケット解析
ちょっと、組み込み装置でamazon S3へのRESTアクセスの調査が必要となった。
RaspberryPiなどの組み込みLinuxでやるのであれば、割と簡単かもしれないが、ガチな組み込み機器であるため、Ethernetドライバ、TCP/IP、HTTP、TLS、RESTみたい感じできっちり理屈で組み上げる必要がある。
SEO Google search consoleからの苦情「クリック可能な要素同士が近すぎます。テキストが小さすぎて読めません。」
Google search consoleから「クリック可能な要素同士が近すぎます。テキストが小さすぎて読めません。」と苦情が来た。
しかも、ほっとくと勝手に解決したりで、なんじゃこれ？
ブログカード等で表示されている文字列。
この文字列のデフォルトは各投稿ページの先頭n文字分なのだが、あまりにも長すぎると苦情がくる。
モーター モーター伝達関数導出
モーターの伝達関数そのものはググればそれなりに出てくる。 しかし、どのように導出したかわからなければその後の調整、応用ができなくなる。
モーターの等価回路から、電圧から電流の伝達式を導出。
モーターの発電原理から角速度から逆起電力の伝達式を導出。
モーターのトルク原理から、電流からトルク、角加速度の伝達式を導出。