UDS::Call_31_0216UDS::Call_35未完待续……
5
ProgEventDispatcher::DispathEvent虽然它分发给所有节点处理器了 但并不是都执行因为有的处理器 没有相关对应参数的ProcessMessage函数之前我从未遇到过该中写法，应该写个demo验证如果不存在该参数类型的虚函数 他到底会怎么办（或者是说 这段代码有问题）
proxy_service::OTA2DB()通过someip回应DB结束(回应Response方式是代理调用服务的方法)
UDS::ForwardMessage
{\"amsr_aptiv_ota_app/RootSwCProto_OTA/OTA_CYS_PortR\"_sv};
ProcessMessage(DID_F1BC_SW_INFO_FROM_RETMOTE_ECU swinfo)
执行完后最终调用下面接收右边执行的结果response
DoIpResp
2、SECURITY_ACCESS计算随机秘钥种子
没想到 还真是右边这种方式请求后立即回复，不管存在不存在如果不存在我就返回正在查找 请稍后.....如果存在我就给你硬件信息
调用
消息源1：高低压目的地DNA_CCUUDS::Call_31_0213UDS::Call_31_0214
ProcessMessage(DID_F1BD_HW_INFO_FROM_RETMOTE_ECU& hwinfo)
UDS::Call_22_F1BC
AA
Cys_Service负责加解密 签名 TEE信任环境相关
1.PortP_CysService SomeIp:291532.
3
CCU_OTA_StatusResp_113_Type
开启计时器请求UDS调用
请求停止上传请求退出
someip自生成代码对应关系 R端 (以OTA的加解密为例)
someip自生成代码对应关系 P端 (以sys的加解密为例)
MPU_Cores/7_Autosar_Model/CCU4.0/src-gen/amsr_aptiv_ota_app/src/amsr/someip_binding/internal/life_cycle_manager.cpp
amsr_aptiv_ota_app/RootSwCProto_OTA/OTA_CYS_PortR 加解密
Exec_CysService/RootSwCProto_CysService/PortP_CysService
SomeIp:29153
特别注意这里是同步调用ThreadManager::SyncInvoke消息源1：高低压目的地DNA_CCUUDS::Call_31_0213UDS::Call_31_0214
1. RCoreUpdateAgent::TransferFile开始传输文件2.开启计时器超时通知报错 没有重发3、通知SSTproxy_service::sst_send_flashinfo_req_111启动刷写吧
LogCollector
日志收集并没有调用代理的方法即没调用别的服务
请求SM模块状态切换
DoCanUdsResp()
Programming : public ProgEventHandler
软硬件信息收集固件
RID_0210_FILE_MD5_CHECKSUM_REQ请求MD5校验工具未处理直接返回成功
RID_0213_CHECK_OTA_MODE_PRECONDITIONS_REQRID_0214_CHECK_OTA_MODE_PRECONDITIONS_REQ这两个消息功能类似SVR_10_81_REQ请求停止OTS模式
CCCCU_ESP_FD2_137_Type仅仅记录_esp_fd2_137值
该模块里面调用过程
Service22Handler
SM_Tester
1.SM_TriggerInOut_Rport SomeIp:287702.
{\"amsr_aptiv_ota_app/RootSwCProto_OTA/OTA_SST_PTPT_PortR\"_sv};
通过SOMEIP请求SM模块切换为升级会话状态
1、proxy_service::sm_has_already_in_ota_mode()请求当期sm的状态是否为OTA模式，如果是则返回否则发送进入OTA模式指令
diag_example_app
1.Diag_APP_OTA_COM_R SomeIp:289612.Diag_APP_CYS_COM_R SomeIp:291533.Diag_APP_SM_COM_R SomeIp:287714.Diag_APP_SST_COM_R SomeIp:28673
好像是这个db联系的是hut2024-01-03 21:21:13
软件版本信息组一 soft version0xf1890xf1c00xf1c1组二 CompID0xf1B40xf1b90xf1be组三 tool version0xf1b6
另外一个不幸的消息 D02开始 目录结构就变了 不是上面的样子了 可能是去读取配置文件了 不再写死
参考MPU_Cores/MPU_Cores/3_Autosar_Platform/Vecto/CBD2100373_D02/BSW/amsr-vector-fs-someipbinding/lib/someip_binding/include/amsr/someip_binding/internal/binding_singleton.h
LifeCycleManager::RegisterServiceInstances() 里面不再有 Rport 和 Pport
MPU_Cores/MPU_Cores/3_Autosar_Platform/Vecto/CBD2100373_D02/BSW/amsr-vector-fs-someipbinding/lib/someip_binding/src/amsr/someip_binding/internal/someipbinding_initializer.cpp
void SomeIpBindingInitializer::RegisterServiceInstances(SomeIpBindingConfig const& config注册P和R
当务之急是 调查 binding_singleton.h 里面哪个配置文件来源
我确实发现了哪个文件 amsr_aptiv_ota_app\\etc\\someipbinding_config.json
之前D01 client端 方法ID所在处 MethodId kMethodId{0x642U};src-gen/amsr_vector_app_example_calculator_client/include/amsr/someip_binding_transformation_layer/internal/vector/calculatorservice/calculatorInterface_proxy_methods.h
之前D01 server端方法ID所在处 MethodId kMethodId{0x642U};model/src-gen/aa/include/amsr/someip_binding_transformation_layer//calculatorservice/calculatorInterface_skeleton_someip_methods.h
留下疑惑 除了 ota 都没有发现配置文件 someipbinding_config.json
后来发现 不是走的 ReadConfigurationFromComponentJson() 而是CopyConfigurationFromSocalRuntime() 自生成代码里面GeneratedConfig::Fill
疑惑解决 参照cys 33249 服务 generated_config.cpp
遇到的疑惑1、diag_req 不应该是空指针 写错了吧
4
还有一条线路是被别人调用DoCanUdsRequest()内部回调
通过someip去请求
SendEvent 同步调用还是异步的调用分析目前还没有意义因为对于调用者 发送线程消息 都是异步的2022-04-01 12:41:13这里一个同步调用ThreadManager::SyncInvoke好像没有用到这个阻塞等待调用2022-04-08 16:44:27后来发现用到了，而且还用的特别多
组二write_data_22_F1BAwrite_data_31_FF01write_data_31_0202write_data_31_0210write_data_31_0211write_data_31_0212write_data_31_0214write_data_31_0215
UpdateAgent
通过UDS::Call然后通过ForwardMessage间接调用
{\"amsr_aptiv_ota_app/RootSwCProto_OTA/OTA_SST_PRIV_PortR\"_sv};
自生成代码 供不同aa使用Exec_Aptiv_App_SMT
1.SM_TriggerInOut_RportSomeIp: 287702.SM_UpdateRequest_Rport 287693.SM_DianosticReset_RPort 28771其它 CYS_CryptoKit_SI_RPort SomeIp:29153
AAECU
处理过程从远程ECU获得软件信息
1、if(swinfo.nrc == pos_res)Get_One_Ecu_Sw_Info_Response这是请求来的结果，把超时计时器清空，发送请求 Get_One_Ecu_Sw_Info_RequestDiagBridgeParser::DoCanUdsRequest重置并启动超时计时器 EVT_TIMER_F1BC_TIMEOUT2、回应是挂起状态则判断是否超过了最大超时次数 超过则请求下一个否则继续请求DiagBridgeParser::DoCanUdsRequest重置并启动超时计时器 EVT_TIMER_F1BC_TIMEOUT3、放弃当前 继续请求下一个ECU软件信息直到结束
发现一个VSCODE的bug，如果不打开那个目录 很有可能搜不到，比如关键字“Diag_APP_OTA_COM_R”MPU_Cores/7_Autosar_Model/CCU4.0/src-gen/diag_example_app/src/amsr/someip_binding/internal/life_cycle_manager.cpp
请求当前安装进度
UpdateAgent::GetInstallationProgress(target)
RemoteUpdateAgent
OTA_UDS_OTHER_SIDUDS::Call_OTHER_SID
入门起步，专门查看SOMEIP消息调用关系
SM_Tester里面有一个test测试该服务的demoAPP
RID_0211_PROG_MD5_CHECKSUM_REQHUT下载日志的时候有效md5完整性RID_0216_HASH_VALUE_REQSHA校验DID_FF01_CHECK_PROG_DEPENDENCY_REQ没用到RID_0212_PKG_SIGNATURE_VERFIYCATION_REQ文件签名 防篡改SVR_14_FF_FF_FF_REQ未使用SVR_22_F0FF_FINGER_PRINT_REQ指纹相关仅仅返回一个时间SVR_2E_F0FF_FINGER_PRINT_REQ
CANoe13400网络
都是组三write_data_22_F1BBwrite_data_22_F1BCwrite_data_22_F1BDwrite_data_31_0216为啥16在这边???
看明白了左侧的疑问父类虚函数都存在，只是子类没有实现所以这个分发线程，仅仅推给了相应的处理线程这种写法第一次见到。
硬件信息三个回应1、0xf1b3node address2、0xf187part number0xf18c3、serial number
{\"amsr_aptiv_ota_app/RootSwCProto_OTA/OTA_DB_PortR\"_sv};
依赖关系
没有逻辑，直接返回了PositiveResponse
组一write_data_35write_data_36write_data_37
整个安波福框架
DID_F1BD_HW_INFO_FROM_RETMOTE_ECU : public ota::REQMessage
DID_FF01_CHECK_PROG_DEPENDENCY_REQ
someip自生成代码对应关系 R端 (以OTA为例)(这是一个错误的例子 否则就是自己调自己了)
someip自生成代码对应关系 P端 (以DB为例)(这是一个错误的例子 否则就是自己调自己了)
src-gen/amsr_aptiv_ota_app/src/amsr/someip_binding/internal/life_cycle_manager.cpp
7_Autosar_Model/CCU4.0/src-gen/amsr_aptiv_ota_app/src/amsr/someip_binding/internal/life_cycle_manager.cpp
amsr_aptiv_ota_app/RootSwCProto_OTA/OTA_DB_PortR
amsr_aptiv_ota_app/RootSwCProto_OTA/OTA_DB_PortP
SomeIp:28865
SomeIp:28962
真正的对应结果不是靠 R-P，而是靠这个 28865 所以这组根本不是一对那个R-P的字符串 仅仅是 服务发现 和服务供应的时候 用的一个字符串
真正的对应结果不是靠 R-P，而是靠这个 28962 所以这组根本不是一对那个R-P的字符串 仅仅是 服务发现 和服务供应的时候 用的一个字符串
AAHUT
_cys_svr->Import_RSA_Key对称加解密相关
OTI
远程升级代理组1、RemoteUpdateAgent::ECU_Reflash_Request2、ECU_REflash_Response_Pending()电子控制单元信息收集组1、EcuInfoCollector::Get_One_Ecu_Sw_Info_Request2、EcuInfoCollector::Get_One_Ecu_Hw_Info_Request3.EcuInfoCollector::Get_One_Ecu_Sw_Info_Timeout_Retry4.EcuInfoCollector::Get_One_Ecu_Hw_Info_Timeout_Retry
DBToOta()别人来的请求
诊断路由
UDS信息中转站
CCU_HW_Status_4ED_Type
SST_Server
1.PPort_SOMEIP_ServiceInterface_SST_Auto_PRIV 286732.PPort_SOMEIP_ServiceInterface_SST_Auto_PTPT 28677
直接返回
2
DM_RequiredService
1.DBToOTA 2.write_data两个函数都是调用下面
多一个50ms睡眠 统计挂起次数通过UDS::Call然后通过ForwardMessage间接调用
打DOIP包
更新进度Update() uint32_t ua_state = _ua_sdk->getUpdateState(); uint8_t ua_progress = _ua_sdk->getUpdateProgress();
RID_0208_START_INSTALLATION_REQ请求安装
Service31Handler
请求打包上传(好像没完成)反馈给请求者文件大小信息
多个过程无法一一介绍如下UDS::Call_31_0202UDS::Call_31_0208 case 0x0210: case 0x0211: case 0x0212: case 0x0213: case 0x0214: case 0x0215: case 0x0216:
3、READ_DATA_BY_ID
1.Process_EVT_TIMER_F1BC_TIMEOUT2.Process_EVT_TIMER_F1BD_TIMEOUT
ota_tester 这是越过DM直接发信号测试用的
1.OTAT_OTA_COM_PortR SomeIp:289612.
通过SOMIP请求核间114请求
告知要升级的文件名称等信息
执行完后最终调用下面DoIpResp
Diag_Bridge
1.DBridge_OTA_RPortPrototype 289622.DBridge_SST_RPortPrototype 286733.DBridge_PPortPrototype 28865
一个是AA (ECU)一个是hut后来我发现请求ECU和回复HUT都是调用的这里的方法proxy_service::OTA2DB()所以我怀疑这里可能是一个转发
EcuInfoCollector
can总线
PkgInfoCollector
还未使用
DiagBridgeParser
1、DoCanUdsRequest()内部回调2、DBToOta()推测 做边的请求 回应是右边 或相反
收到的请求消息直接调用SST方法估计是请求某些信息
sst_send_ota_req_114()sst_send_otainfocmd_req_115()
1
someip自生成代码对应关系 R端 (以OTA为例)
someip自生成代码对应关系 P端 (以DB为例)
MPU_Cores/7_Autosar_Model/CCU4.0/src-gen/diag_bridge/src/amsr/someip_binding/internal/life_cycle_manager.cpp
diag_bridge/DBridge_RootSwComponentPrototype/DBridge_PPortPrototype
SomeIp:28865 对应类 namespace proxy_service
SomeIp:28962 对应类 OtaMsgReceiver
收到SST订阅消息EVT_SST_CCU_FLASHINFO_RESP_112
{\"amsr_aptiv_ota_app/RootSwCProto_OTA/OTA_SM_UpdateRequest_PortR\"_sv};
好像是这个dm联系的是诊断aa2024-01-03 21:21:13
未通过ForwardMessage直接调用
DID_F1BC_SW_INFO_FROM_RETMOTE_ECU : public ota::REQMessage
收到的分区信息
1、 打印收到的消息 应该是IPC核间 R核那边来的2、AppConfig::emmc_bank AppConfig::var_bankAppConfig::nor_bank 存储三个值
CCU_OTAInfoCMP_116_Type仅仅记录_ota_info_cmp_116值
SST模块
和左侧一样
1、右侧：存在消息则直接反馈给HUTspan style=\"font-size:inherit;\
DID_F1BA_INSTALLATION_PROGRESS_REQ
好像是请求传输进度把进度结果反馈给请求者
4、ROUTINE_CONTROL
RID_0215_NOTIFY_FILE_NAME_REQ
DB_RequiredService
SelfUpdateAgent
UDS::Call_22_F1BD
网络总线
CCU_FlashInfoResp_112_Type未处理
1、被PROG调用UpdateAgent::Execute_pkg_path会被赋值2、RCoreUpdateAgent::Start()
SMApplication
1.TriggerInOutProviderPort SomeIp:287702.UpdateRequestProviderPort 287693.DianosticResetProvidePort 28771==========================4.SSTConsumerPort R-Port 28673 CCU_Reset_Manager_GW_To_Acore_34_Ev_SOMEIP.SetReceiveHandler 订阅了 SST的下面方法 调用MPU_Cores/5_Aptiv_App/SST_Server/libSST_Server/src/DBC00_service_skeleton.cpp CCU_Reset_Manager_GW_To_Acore_34_Ev_SOMEIP.Send(*((datatypes::sst_auto_priv::CCU_Reset_Manager_GW_To_Acore_34_Type*)data)); 调用SST的 预备重置 proxy->SomeipSetEvent(RequestResetConfigure::kEventId 调用SST的 确定重启 proxy->SomeipSetEvent(RequestResetConfigure::kEventId
DoCanUdsRequest()内部回调DiagBridgeParser::OtaToDB同样都是这个函数下面红色是回应这里确实请求
这里好像是来自HUT的请求 看参数
1、如果信息存在则返回2、如果是空闲状态则通知左侧模块 请求软件信息3、这样我推算左侧的消息是和ECT通信，四步消息
RCoreUpdateAgent
2022-04-08 15:23:58新发现 获取软硬件信息是同步调用ThreadManager::SyncInvoke这也就解释了 他为什么能立即返回
class PkgInfoCollector : public ProgEventHandler文件名pkg_info_collector.h
创建一块共享内存
好像是从共享内存中读取一块数据
EcuInfoCollector::ProcessMessage(CCU_OTAInfoCMP_116_Type *data)
DoIpRequest()
1.ProcessMessage(CCU_FlashInfoResp_112_Type *)一个SST发来的通知 要求刷写R核软件包2.RCoreUpdateAgent::Update()定时调用一个定时器定时更新进度3、这个消息最重要的功能室打开了共享内存通知了SSTPackageUtil()NormalOP()
ThreadManager::SyncInvoke消息源1：高低压目的地DNA_CANUDS::Call_31_0213UDS::Call_31_0214
DBToOta()别人来的回应
UA
RID_0202_CHECK_PROG_PRE_CONDITION_REQ请求是否符合升级条件默认返回速度是否合格开车过程中不允许升级
OTA_Service
1.OTA_DB_PortP 289622.OTA_PortP SomeIp:289613.OTA_DB_PortR 288654.OTA_SM_TriggerInOut_PortR 287705.OTA_SM_UpdateRequest_PortR 28769未使用6.OTA_SST_PRIV_PortR 286737.OTA_SST_PTPT_PortR 286778.OTA_CYS_PortR SomeIp:29153
某条件直接返回估计是会话未建立连接秘钥不正确之类
proxy_service
两个属于SST 一个和SM模块 切换升级状态
下列processMessage消息
1、SESSION_CONTROL开启5s超时计时器后设置doip负载
