OSATE总线延迟的源码分析与模型修复——针对 Latency-case-study项目 端到端流延迟分析过程中空指针异常的解决

本文主要是介绍OSATE总线延迟的源码分析与模型修复——针对 Latency-case-study项目 端到端流延迟分析过程中空指针异常的解决,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、背景

 在文章AADL 端到端流延迟分析示例项目 Latency-case-study 简述的 “第八章 进行系统的端到端流延迟分析” 中,遇到了这样的一个问题:对分布式系统的端到端流延迟进行分析时,没有生成流延迟分析报告,并且错误日志提示,出现内部错误“空指针异常”。

上述文章给出的解决方案是使用旧版本的OSATE,但是这并未真正地解决问题。将OSATE项目的源代码下载,进行调试和分析,结果如下:

在涉及到总线的端到端延迟分析过程中,只将“在end to end flow中涉及的连接” 添加到指定数据结构connectionsToContributors。如果一个连接绑定到了某总线,却未在某个end to end flow中声明,那么该连接便不会添加到connectionsToContributors中,由此导致connectionsToContributors缺少关于该连接的数据,导致空指针异常。

本文在最后给出了修改后的代码,以下为详细内容:

二、问题回顾

对于Latency-case-study项目,在生成integration.software_distributed实例之后,启用流延迟分析,发现并未有任何报告被生成:

错误日志(Error Log)显示如下:

java.lang.NullPointerException: Cannot invoke "org.osate.analysis.flows.model.LatencyContributor.addSubContributor(org.osate.analysis.flows.model.LatencyContributor)" because "latencyContributor" is nullat org.osate.analysis.flows.FlowLatencyAnalysisSwitch.fillInQueuingTimes(FlowLatencyAnalysisSwitch.java:1465)at org.osate.analysis.flows.FlowLatencyAnalysisSwitch.invokeOnSOM(FlowLatencyAnalysisSwitch.java:1052)at org.osate.analysis.flows.handlers.CheckFlowLatency.analyzeInstanceModel(CheckFlowLatency.java:158)at org.osate.ui.handlers.AbstractInstanceOrDeclarativeModelReadOnlyHandler.analyzeInstanceModelInMode(AbstractInstanceOrDeclarativeModelReadOnlyHandler.java:126)at org.osate.ui.handlers.AbstractInstanceOrDeclarativeModelReadOnlyHandler.doAaxlAction(AbstractInstanceOrDeclarativeModelReadOnlyHandler.java:101)at org.osate.ui.handlers.AbstractInstanceOrDeclarativeModelModifyHandler.processAaxlAction(AbstractInstanceOrDeclarativeModelModifyHandler.java:58)at org.osate.ui.handlers.AbstractAaxlHandler.actionBody(AbstractAaxlHandler.java:181)at org.osate.ui.handlers.AaxlReadOnlyHandlerAsJob$ActionAsJob.runInWorkspace(AaxlReadOnlyHandlerAsJob.java:115)at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:43)at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

可以看到,内部错误的主要原因是因为“ "latencyContributor" is null 

三、问题详细分析

为什么会产生空指针异常,接下来将自上而下地对问题进行分析:

在整个分析过程中,对于连接延迟的计算,涉及到了一个Map对象connectionsToContributors,其定义如下:(FlowLatencyAnalysisSwitch.java : line 111)

/** Map from (bus component, connection instance) -> latency contributor. We need this because the queuing latency is computed at the end of process* after all the transmission times are computed. So we add the queuing latency to this latency contributor for the connection instance* bound to the given bus. This may contain entries that in the end are not interesting because virtual buses can be bound to* other virtual buses that are eventually bound to real bus. We chases down all those layers.*/private final Map<Pair<ComponentInstance, ConnectionInstance>, LatencyContributor> connectionsToContributors = new HashMap<>();

在流延迟分析过程中,会将端到端流中的元素按照类型依次添加到对应的Map中(其中一个Map用来存储关于连接的组件,即上面提到的connectionsToContributors),代码如下:

(FlowLatencyAnalysisSwitch.java : mapFlowElementInstance() : line 187)

public LatencyReportEntry analyzeLatency(EndToEndFlowInstance etef, SystemOperationMode som,boolean asynchronousSystem) {LatencyReportEntry entry = new LatencyReportEntry(etef, som, asynchronousSystem, report.isMajorFrameDelay());for (FlowElementInstance fei : etef.getFlowElements()) {mapFlowElementInstance(etef, fei, entry);}// Issue 1148 moved this somewhere else// entry.finalizeReportEntry();return entry;
}

上述代码中,会遍历所有的端到端流etef(end to end flow),将每个端到端流fei(Flow Element Instance)作为参数传递给函数mapFlowElementInstance(etef, fei, entry),而该函数会间接调用processSamplingAndQueuingTimes(),从而根据端到端流的组成元素,向Map connectionsToContributors 中添加元素(只有在端到端流中声明的元素才会被添加),代码如下:(FlowLatencyAnalysisSwitch.java : processSamplingAndQueuingTimes():line 896)

	//通过下面函数获取总线的周期,对于周期性总线和非周期性总线,延迟的计算方式不同。double period = hasPeriod.contains(cc) ? PropertyUtils.getScaled(TimingProperties::getPeriod, boundBusOrRequiredClassifier, TimeUnits.MS).orElse(0.0)    :   0.0;// 如果是周期性总线,增加采样延迟,将排队延迟设为0if (period > 0) {// add sampling latency due to the protocol or bus being periodicLatencyContributor samplingLatencyContributor = new LatencyContributorComponent(boundBusOrRequiredClassifier, report.isMajorFrameDelay());samplingLatencyContributor.setBestCaseMethod(LatencyContributorMethod.SAMPLED_PROTOCOL);samplingLatencyContributor.setWorstCaseMethod(LatencyContributorMethod.SAMPLED_PROTOCOL);samplingLatencyContributor.setSamplingPeriod(period);latencyContributor.addSubContributor(samplingLatencyContributor);// add queuing latency: always zero in this caseLatencyContributor queuingLatencyContributor = new LatencyContributorComponent(boundBusOrRequiredClassifier, report.isMajorFrameDelay());queuingLatencyContributor.setBestCaseMethod(LatencyContributorMethod.QUEUED);queuingLatencyContributor.setWorstCaseMethod(LatencyContributorMethod.QUEUED);queuingLatencyContributor.setMinimum(0.0);queuingLatencyContributor.setMaximum(0.0);latencyContributor.addSubContributor(queuingLatencyContributor);} //如果是非周期性总线,需要在后续过程中计算排队延迟,将其存储于Map中else {/** Issue 1148** if "boundBus" is really a bound component instance, and not a required component classifier,* then we remember the bus as asynchronous. Later in fillInQueuingTimes() we go through this list,* and then find all the connection instances bound to this bus. For each connection,* we compute the sum of the max transmission times of the OTHER connections bound to the bus. This* we set as the worse case queuing time. (Best case is 0.)** We also remember the bus--connection pair that needs the queuing latency by storing its latency contributor.*/if (bindingConnection != null) {final ComponentInstance boundBus = (ComponentInstance) boundBusOrRequiredClassifier;/* Set the bus order and then add it to the ordered set */if (!busOrder.containsKey(boundBus)) {busOrder.put(boundBus, nextBusId++);asyncBuses.add(boundBus);}connectionsToContributors.put(new Pair<>(boundBus, bindingConnection), latencyContributor);}

根据上述代码:对于周期性总线和非周期性总线,其延迟的计算方式不同。

对于周期性总线,计算它的采样延迟,范围为[0, period]。

对于非周期性总线,其最小延迟为0,最大延迟按照绑定到该总线的其他连接的数据传输时间之和进行计算。

因此,对于端到端流延迟分析函数的调用代码,涉及到了一个名为 fillInQueuingTimes()的函数,其源码如下:(FlowLatencyAnalysisSwitch.java : fillInQueuingTimes():line 1412)

	private void fillInQueuingTimes(final SystemInstance system) {// Nothing to do if there are no asynchronous busesif (!asyncBuses.isEmpty()) {// Get all the connections bound to a bus and group them together by the bus they are bound tofinal Map<ComponentInstance, Set<ConnectionInstance>> sortedConnections = sortBoundConnections(system);/** Go through the list of all the asynchronous buses*/for (final NamedElement ne : asyncBuses) {// only proceed if it is a bus instance and not a classifier (from Required_Virtual_Bus_Class)if (ne instanceof ComponentInstance) {final ComponentInstance bus = (ComponentInstance) ne;// Get all the connections bound to that busfinal Set<ConnectionInstance> boundConnections = sortedConnections.getOrDefault(bus,Collections.emptySet());// Get all the transmission times and compute the totaldouble totalTime = 0.0;final Map<ConnectionInstance, Double> transmissionTimes = new HashMap<>();for (final ConnectionInstance ci : boundConnections) {final Double time = computedMaxTransmissionLatencies.getOrDefault(new Pair<ComponentInstance, ConnectionInstance>(bus, ci), 0.0);transmissionTimes.put(ci, time);totalTime += time;}/** Go through the list of connections again, and subtract the time associated* with the current connection to find the max waiting time for each connection.* (That each for each connection ci, we will have the sum of all the times* for the _other_ connections bound to same bus. This gives us the max* time that connection ci may have to wait to use the bus.)*/for (final ConnectionInstance ci : boundConnections) {final Double ciTime = transmissionTimes.get(ci);final double maxWaitingTime = totalTime - ciTime;// Finally we can stick this into the latency contributorfinal LatencyContributor latencyContributor = connectionsToContributors.get(new Pair<>(bus, ci));final LatencyContributor queuingLatencyContributor = new LatencyContributorComponent(bus,report.isMajorFrameDelay());queuingLatencyContributor.setBestCaseMethod(LatencyContributorMethod.QUEUED);queuingLatencyContributor.setWorstCaseMethod(LatencyContributorMethod.QUEUED);queuingLatencyContributor.setMinimum(0.0);if (report.isDisableQueuingLatency()) {// Hide the queuing timequeuingLatencyContributor.setMaximum(0.0);queuingLatencyContributor.reportInfo("Ignoring queuing time of " + maxWaitingTime + "ms");} else {// Report the queuing timequeuingLatencyContributor.setMaximum(maxWaitingTime);}latencyContributor.addSubContributor(queuingLatencyContributor);// add the sampling latencyLatencyContributor samplingLatencyContributor = new LatencyContributorComponent(bus, report.isMajorFrameDelay());samplingLatencyContributor.setBestCaseMethod(LatencyContributorMethod.SAMPLED_PROTOCOL);samplingLatencyContributor.setWorstCaseMethod(LatencyContributorMethod.SAMPLED_PROTOCOL);samplingLatencyContributor.setSamplingPeriod(0.0);latencyContributor.addSubContributor(samplingLatencyContributor);}}}}}

在上述代码中,首先会获取一条总线上绑定的所有连接。

final Set<ConnectionInstance> boundConnections = sortedConnections.getOrDefault(bus,Collections.emptySet());

然后依次遍历每条连接,在Map connectionsToContributors中定位到这个连接并向其中添加延迟贡献。

final LatencyContributor latencyContributor = connectionsToContributors.get(new Pair<>(bus, ci));

......

latencyContributor.addSubContributor(queuingLatencyContributor);

异常出现的原因:如果一个连接没有被包含于某个端到端流,但是却被绑定到总线上,那么Map connectionsToContributors将不会添加此连接,故而在遍历绑定到总线的连接时,会出现空指针异常。

四、解决方案

修复此问题的方法有2种:

1. 完整地建模,声明系统中存在的所有端到端流,以保证不会有连接被遗漏。

2. 设定总线周期,避免排队延迟情况的出现(即绕过排队延迟计算)。

五、修复模型并测试

两种方案的代码如下:(在 integration.aadl 的 integration.software_distributed 部分)

system implementation integration.software_distributed extends integration.software_genericsubcomponentss1_cpu 	: processor latency_cs::platform::generic_cpu;s2_cpu 	: processor latency_cs::platform::generic_cpu;p_cpu 	: processor latency_cs::platform::generic_cpu;a_cpu 	: processor latency_cs::platform::generic_cpu;s_p_bus: bus latency_cs::platform::generic_bus;p_a_bus : bus latency_cs::platform::generic_bus;connectionsb0 : bus access s1_cpu.net <-> s_p_bus;b1 : bus access s2_cpu.net <-> s_p_bus;b2 : bus access p_cpu.net <-> s_p_bus;b3 : bus access p_cpu.net <-> p_a_bus;b4 : bus access a_cpu.net <-> p_a_bus;-- 为解决流延迟分析过程中出现的空指针异常而增添的代码---------------- 方法1.完整地建模,声明系统中存在的所有端到端流(在flows中声明)flowsetef2 : end to end flow s1.sensor_source -> c0 -> p.sink0; etef3 : end to end flow s2.sensor_source -> c1 -> p.sink1;-- ---------------------------------------------------------------properties-- 为解决流延迟分析过程中出现的空指针异常而增添的代码------------ 方法2.设定总线周期(在properties中设定)--	Period => 5ms applies to s_p_bus, p_a_bus;-- -----------------------------------------------------------actual_processor_binding => (reference (s1_cpu)) applies to s1;actual_processor_binding => (reference (s2_cpu)) applies to s2;actual_processor_binding => (reference (p_cpu)) applies to p;actual_processor_binding => (reference (a_cpu)) applies to a;actual_connection_binding => (reference (s_p_bus)) applies to c0;actual_connection_binding => (reference (s_p_bus)) applies to c1;actual_connection_binding => (reference (p_a_bus)) applies to c2;-- protocol that applies to the connectionsrequired_virtual_bus_class => (classifier (latency_cs::platform::generic_protocol)) applies to c0, c1, c2;
end integration.software_distributed;

1. 完整地建模,声明系统中存在的所有端到端流,实例化后进行分析:

成功生成流延迟分析报告:

报告内容如下所示:

2. 设定总线周期,避免排队延迟情况的出现

成功生成流延迟分析报告:

报告内容如下所示:

六、相关链接

 OSATE 开发者文档,展示了如何部署环境并拉取OSATE源码,如下:

Setting up an OSATE development environment — OSATE 2.13.0 documentation

OSATE 项目的源码也可以直接在github下载:

osate/osate2: Open Source AADL2 Tool Environment (github.com)

latency-case-study项目的源码也可以直接在github下载:

examples/latency-case-study at master · osate/examples (github.com)

 修改后的完整的项目代码可在此处下载。

【免费】latency-case-study项目修改版(资源-CSDN文库)

如有不当或错误之处,恳请您的指正,谢谢!!!

这篇关于OSATE总线延迟的源码分析与模型修复——针对 Latency-case-study项目 端到端流延迟分析过程中空指针异常的解决的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/326237

相关文章

部署Vue项目到服务器后404错误的原因及解决方案

《部署Vue项目到服务器后404错误的原因及解决方案》文章介绍了Vue项目部署步骤以及404错误的解决方案,部署步骤包括构建项目、上传文件、配置Web服务器、重启Nginx和访问域名,404错误通常是... 目录一、vue项目部署步骤二、404错误原因及解决方案错误场景原因分析解决方案一、Vue项目部署步骤

JavaScript中的reduce方法执行过程、使用场景及进阶用法

《JavaScript中的reduce方法执行过程、使用场景及进阶用法》:本文主要介绍JavaScript中的reduce方法执行过程、使用场景及进阶用法的相关资料,reduce是JavaScri... 目录1. 什么是reduce2. reduce语法2.1 语法2.2 参数说明3. reduce执行过程

mybatis和mybatis-plus设置值为null不起作用问题及解决

《mybatis和mybatis-plus设置值为null不起作用问题及解决》Mybatis-Plus的FieldStrategy主要用于控制新增、更新和查询时对空值的处理策略,通过配置不同的策略类型... 目录MyBATis-plusFieldStrategy作用FieldStrategy类型每种策略的作

Springboot中分析SQL性能的两种方式详解

《Springboot中分析SQL性能的两种方式详解》文章介绍了SQL性能分析的两种方式:MyBatis-Plus性能分析插件和p6spy框架,MyBatis-Plus插件配置简单,适用于开发和测试环... 目录SQL性能分析的两种方式:功能介绍实现方式:实现步骤:SQL性能分析的两种方式:功能介绍记录

Python Jupyter Notebook导包报错问题及解决

《PythonJupyterNotebook导包报错问题及解决》在conda环境中安装包后,JupyterNotebook导入时出现ImportError,可能是由于包版本不对应或版本太高,解决方... 目录问题解决方法重新安装Jupyter NoteBook 更改Kernel总结问题在conda上安装了

golang内存对齐的项目实践

《golang内存对齐的项目实践》本文主要介绍了golang内存对齐的项目实践,内存对齐不仅有助于提高内存访问效率,还确保了与硬件接口的兼容性,是Go语言编程中不可忽视的重要优化手段,下面就来介绍一下... 目录一、结构体中的字段顺序与内存对齐二、内存对齐的原理与规则三、调整结构体字段顺序优化内存对齐四、内

Goland debug失效详细解决步骤(合集)

《Golanddebug失效详细解决步骤(合集)》今天用Goland开发时,打断点,以debug方式运行,发现程序并没有断住,程序跳过了断点,直接运行结束,网上搜寻了大量文章,最后得以解决,特此在这... 目录Bug:Goland debug失效详细解决步骤【合集】情况一:Go或Goland架构不对情况二:

0基础租个硬件玩deepseek,蓝耘元生代智算云|本地部署DeepSeek R1模型的操作流程

《0基础租个硬件玩deepseek,蓝耘元生代智算云|本地部署DeepSeekR1模型的操作流程》DeepSeekR1模型凭借其强大的自然语言处理能力,在未来具有广阔的应用前景,有望在多个领域发... 目录0基础租个硬件玩deepseek,蓝耘元生代智算云|本地部署DeepSeek R1模型,3步搞定一个应

redis群集简单部署过程

《redis群集简单部署过程》文章介绍了Redis,一个高性能的键值存储系统,其支持多种数据结构和命令,它还讨论了Redis的服务器端架构、数据存储和获取、协议和命令、高可用性方案、缓存机制以及监控和... 目录Redis介绍1. 基本概念2. 服务器端3. 存储和获取数据4. 协议和命令5. 高可用性6.

解决jupyterLab打开后出现Config option `template_path`not recognized by `ExporterCollapsibleHeadings`问题

《解决jupyterLab打开后出现Configoption`template_path`notrecognizedby`ExporterCollapsibleHeadings`问题》在Ju... 目录jupyterLab打开后出现“templandroidate_path”相关问题这是 tensorflo