面向教育汽车软件工程的AUTOSAR静态测试策略

原创 智能汽车开发者平台 2022-09-13 18:00
摘要


AUTOSAR(汽车开放系统架构)是欧洲汽车领域软件开发的领先架构基础。然而,由于存在大量不同的工具、规范和架构指南,其本身就很复杂,所以使用时更复杂。因此,汽车软件工程领域的学生需要指导和手段,以快速和可理解的方式评估他们的编程输出是否符合标准。基于之前提出的汽车软件工程的教育云平台,在本文中提出了一种评估基于AUTOSAR的软件开发质量的方法。这种方法被定位为开发过程中的一个步骤,学习者最终会在测试驱动过程中运行实现,以评估其实际性能。在这样的测试基础设施中,关于测试执行的资源总是短缺的,因为真正的测试驱动涉及相当复杂的准备工作和时间表。但在采用软件或硬件在环模拟的情况下,也需要协调执行。因此,本文描述的方法有两方面的重点。一方面,希望在更稀缺的资源(如模拟器或真正的测试车辆)被分配之前,尽快捕捉方法上的错误。为此,我们提出了专门用于评估基于AUTOSAR实现的静态测试方法。希望避免实际运行必然会失败的实现。另一方面,上述方法的输出应使学习者和开发者更容易评估和比较其结果的质量。

I.简介
在过去的15年里,汽车领域的软件开发经历了很多的重新调整和改进,包括对现有方法论的改进以及新方法的建立。今天,软件组件的模块化、可重用性和可测试性等方面被认为与实际功能同等重要。因此,旨在减轻确保这些特性所需精力的架构已经被开发出来。其中一个框架是AUTOSAR(Automotive Open System Architecture),它是欧洲汽车软件工程的事实上的标准。本质上,由于涉及许多不同的要求和企业,AUTOSAR是一个非常复杂的话题,拥有一个陡峭的学习曲线,需要大量的经验才能有效地工作。因此,开发人员需要应用不同领域的知识,如硬件开发、通信系统和软件工程。此外,汽车开发人员必须在资源受限的系统中操作,需要比非嵌入式编程(如网络开发)更有效地使用。AUTOSAR引入了以功能为导向的应用开发范式。它将电子控制单元(ECU)的系统结构分成三个水平层--应用层、运行时环境(RTE)和基本软件。应用层的开发是独立于目标平台的。因此,在开发新功能时,需要花费相对较长的时间,直到开发人员能够观察到他们的代码在真实车辆的真实硬件上运行,而这两者在开发开始时可能根本不存在。在此之前,将对实施方案进行大量的测试,以确保质量并且符合AUTOSAR标准,并暴露出需要返工的地方。此外,每个测试步骤都需要获得更多有限的测试资源,例如单元测试平台、硬件/软件在环解决方案和最终的真实测试车辆。图1说明了V型模型中开发过程中的各种测试步骤,这是在嵌入式汽车软件开发中使用的主要过程模型。然而,这种设置使得开发人员,特别是学习者,很难及时检索反馈信息,或者以简洁的方式评估、可视化以及比较他们的进展。因此,一个测试步骤越早进行,其结果就应该越快得到,对稀缺资源的依赖也就越少。满足这些要求的一种方法是静态代码分析。在本文中指出静态代码分析在多大程度上可用于基于AUTOSAR的软件的早期测试和评估。此外,将展示AUTOSAR特定的静态测试如何为汽车学习者和开发人员提供比通用静态代码分析更多的好处。

图 1.  标明测试阶段的V模型



II.相关工作
静态代码分析是软件测试方法学的一个重要组成部分。它是通过在语法和语义层面上分析源代码来进行的,但不需要实际编译和执行。静态代码分析被用作一种手段,以发现开发人员常犯的错误,这些错误不会导致编译器错误,但很可能表现为运行时故障—一个众所周知的例子是在Java中使用引用相等来比较字符串。此外,静态代码分析工具1也经常被用来确保遵守代码准则,如项目范围内一致的标识符命名。统一的风格是可取的,以减少团队成员在接手别人的源代码时的学习难度,并方便编码审查。此外,当还没有完全可编译和可执行的原型时,静态分析可以在早期开发阶段发现问题。这是一种节约成本和开发资源的手段,因为通常在开发过程中越晚发现缺陷,修复的成本就越高,这是由模型和现实世界研究提出的。此外,静态代码分析经常被用来搜索导致软件安全漏洞的缺陷。事实上,在行业中生效的一些安全规范要求使用静态代码分析2。根据所使用的编程语言,存在着大量不同的静态分析工具。由于AUTOSAR是C标准,可以使用针对C的静态分析工具。在这个领域,一些现有的和不断开发的工具是Infer、Coverity和Splint。作为一个特例,Clang3值得一提,它本身是一个编译器,但也提供一个静态分析器。这些工具是报告内容方面的通用工具。一方面,这些是警告或错误,暗示着可能的运行时问题,另一方面,可能的输出是代码质量指标。这样的指标提供了一种快速的方法来评估代码库的总体性质和质量。它们的范围可以从最简单的代码行数、评论与代码比率到更复杂的,如循环复杂性。然而,通用工具只能检查有关编程语言的常见错误,并执行风格指导,但不能详尽地分析AUTOSAR项目,因为它们没有考虑到领域知识。这主要是由于AUTOSAR项目由模块化的源代码文件和大量的配置文件组成,这些文件是相互依赖的。在此基础上,配置是AUTOSAR项目的一个非常复杂和关键的方面。因此,许多错误都与配置有关,特别是在早期开发阶段。例如,定义的端口或属性实际上没有被实现,或者配置和实现的行为之间不匹配。这些错误不可能用标准的C语言静态分析工具发现,因为这些工具只在源代码层面上操作。

在[7]中,作者使用三种常见的静态分析工具,对AUTOSAR软件组件的可测试性进行了研究。然而,他们只评估了有关C语言编程的常见错误,而没有评估与AUTOSAR配置有关的错误。因此,最近提出了专门为测试AUTOSAR项目设计的静态测试方法。  在教育背景下,为学习者提供一种简单易懂的方式来评估他们自己的表现或进步也很重要。此外,还需要一个指标来比较相互竞争的实施方案,以便选择应该被看好的解决方案进行进一步测试。因此,在本文中提出了一个在汽车软件工程教育背景下的AUTOSAR项目的静态分析方法。与一般用途的提示器一样,这种方法提供了质量指标和可能的错误检测,但以AUTOSAR特定的方式,使其对汽车领域的学习者和开发者更加有用。此外,还会根据检测到的问题提供纠正建议。本文展示了如何利用这些静态分析来评估和提高AUTOSAR项目的质量。


III.AUTOSAR特定静态分析
如前所述,本文提出的方法有两个目的,一方面是为开发人员,特别是学习者提供一个简单而便捷的方法来评估他们的表现,另一方面是在动态和集成测试阶段之前提高汽车软件项目的质量。提出方法与V型模型中的四个主要发展里程碑相结合,如图1所示(M1至M4)。在第一个里程碑中,支持的对象是单个功能的开发者,他们会根据所进行的静态分析得到提示。这提高了AUTOSAR项目在实施过程中的代码库质量,确保了与标准有关的一致行为,并通过纠正建议促进了学习效果。第二个里程碑在正常测试过程开始之前。这里进行的检查可能比在里程碑一的检查更严格。例如,对某些模式的遵守可以被强制执行,而在第一步中只建议更改。这是必要的,因为开发人员可能会在(原型)开发期间忽略提示,或者以非标准兼容的方式合并建议的纠正。因此,在这个里程碑的分析确保了测试过程开始前的预期质量水平。事实上,如果使用虚拟验证平台,这个里程碑可能存在两次。在这种情况下,在V模型中建立第二个测试分支(见图1),并在虚拟平台上测试AUTOSAR应用之前执行检查。然后在V模型的右侧分支中正常处理常规测试流程。在目标ECU上动态测试实际代码之前的第三个里程碑,不仅要检查应用程序的质量,还要检查基本软件(BSW)和RTE。这可能是这个过程中最重要的一步,因为AUTOSAR提供了大量的参数作为ECU配置的一部分。这个配置需要以一种特定于应用程序的方式创建,这意味着在这一点上的修改可能也需要对应用程序进行调整。第四个里程碑位于开发过程的后期,对整个 AUTOSAR 项目的质量进行评估,因此涉及的检查可能与之前的检查非常不同。这个里程碑的想法是确保应用程序的高质量,并评估它们是否适合被添加到跨项目的汽车库中。该库中的应用将在其他项目中以新的配置重新使用,因此要遵守更严格的合规性和兼容性要求。特别是通过第二和第四个里程碑的检查,可以对参与项目的开发人员进行分类或评估。因此,它们已被用作AUTOSAR软件工程自适应学习概念的一部分。总之,里程碑M1至M4的检查旨在实现AUTOSAR开发的以下方面:
M1  通过改正建议为个别开发者提供支持
M2 对AUTOSAR应用的分析,以及对目前开发草案RTE部分内容的分析
M3  对BSW和最终RTE应用特定的检查
M4  应用特定的BSW和RTE的动态测试,适合于整合到库中
图 2.  静态测试AUTOSAR
如图2所示,AUTOSAR项目主要由配置文件和源代码组成,这些文件都是由提出的静态测试来分析的。这些测试与实际使用的工具链无关,只要对正式的、标准化的文件进行分析即可。该分析建立在一个广泛的知识库上,其中包含AUTOSAR的架构信息。该知识库主要包括BSW及其模块以及RTE的信息。每个AUTOSAR版本的信息都是单独存储的,从而能够支持针对不同版本和供应商堆栈的并行开发。每个静态分析都可能产生一个修正建议,包括对程序员的解释。如果应用了此修正,并且项目文件发生了更改,那么该检查也将重新运行。这就避免了在项目中因错误应用纠正建议而造成的错误。如果在分析过程中确实发生了问题,但没有进行修正,则在分析报告中增加一个单独的报告条目。该报告条目包含关于文件、行号和分析模块的信息。
A. 分析的对象
静态分析的对象是某AUTOSAR项目的文件。这包括所有架构层,即应用、BSW和RTE。除了在每个文件的基础上进行分析外,我们还解决和比较不同位置和层之间的属性问题。 
虽然AUTOSAR项目可以由不同供应商的不同工具创建,但它通常由以下类型的文件组成:
●   源代码文件(c和h文件)
●   AUTOSAR标准规定的配置文件
●   供应商指定的配置文件
该静态分析是基于对所谓方面的定义。一个方面确定了相关分析的调查重点。目前,对于每个被分析的项目,可以定义一组具有以下属性的问题:
●  颗粒度
●   AUTOSAR 层
一个方面的粒度目前可以是三个不同的类别之一--文件、函数和代码/配置行,如表I所示。
相应的,AUTOSAR层方面是应用层、BSW和RTE。每一个方面a的分析都会产生一个相应的覆盖值cva,它是成功检查的实体数量(取决于粒度)和这个方面中实体总数之间的比率,例如cva = #检查的entitiesa /#entitiesa(#是基数)。
B. AUTOSAR一致性等级
一组覆盖率值可用于计算AUTOSAR软件项目或项目部分的单一、整体质量值。这种综合指标称为 AUTOSAR 一致性水平 CL。让cva指定给定方面a的一致性值和ωa的严重度,那么集合A中各方面的CL可以用以下方法计算:

其结果是一个单一的值,它提供了一个简明的方法来快速评估AUTOSAR项目在标准一致性方面的质量。在下一节中,将展示如何使用一致性值和级别来提高资源利用率和开发人员在基于AUTOSAR的汽车开发和测试基础设施中的反馈。



IV.应用和用例

对于汽车软件工程研究课程的发展,我们已经建立了工作流程,如图3所示,该流程已在[4]中提出。在那里,学习者可以在基于AUTOSAR的实施方案的开发周期中承担不同的角色。它们得到了两个工具的支持。ASTAS(AUTOSAR系统的应用规格测试)和TUC驱动云。前者提供了测试AUTOSAR ECU的方法,而后者则提供了一个测试驱动管理接口,以及访问汽车测试驱动数据的大数据存储的标准化方法。
图 3.  已部署的汽车软件工程工具链与图1中注释的测试步骤
由于本文提出的AUTOSAR特定静态测试已被整合到ASTAS中,本节将把重点放在这里。图4说明了测试AUTOSAR项目的原型的工作流程,以及ASTAS在这个过程中的整合。ASTAS包含用于分析AUTOSAR项目的软件模块和用于AUTOSAR ECU动态测试的软件模块。除了AUTOSAR特定的静态测试,ASTAS还支持以连续的方式对BSW和RTE进行应用特定的测试。这种测试方法是用符合AUTOSAR的方法实现的,并支持错误定位。知识库包含了在目标平台上实现动态测试的所有必要信息。关于这种方法的细节在[18]中解释。除了自有的功能之外,还整合了一个商业工具链,用于代码分析、构建和测试。在开发和教学过程中,从以下方面检查项目:
●    AUTOSAR应用之间的连接(M1, M2)
●   符合AUTOSAR BSW(M2)的要求
●   产生的RTE与应用程序和BSW的一致性(M2, M3)
●   整个AUTOSAR应用的一致性(M1, M4)
图 4.  通过ASTAS和集成工具链测试AUTOSAR系统的工作流程
图 5.  应用程序中软件组件之间未连接端口的例子
第一个检查是评估应用程序内通信的一致性。AUTOSAR在应用中定义了所谓的软件组件,它代表了ECU的实际功能。为了实现部分或完整应用的可重复使用性,软件组件内的通信需要符合标准。然而,遵守标准通常意味着实施者要做额外的工作,而学习者往往在一开始就尽量避免。因此,在实施过程中,使用这种考核是确保软件质量的一个非常重要的辅助手段。AUTOSAR ECU的BSW是根据映射的应用进行配置的,由一组不同的模块组成。为了确保符合标准,第二次评估根据应用情况检查项目中的集成和配置模块。这一步骤确保了应用程序在以后开发中的可扩展性。在实施应用和配置BSW之后,AUTOSAR方法论规定了RTE的生成。这是在目标平台上测试前的最后一步。由于不同的层(RTE、BSW、Application)可以使用不同的工具进行开发,AUTOSAR ECU的所有三个层的一致性需要得到确认。这种检查避免了测试过程后面步骤中代价高昂的错误定位。第四个方面是单独测试应用程序。它包含关于代码合规性、架构和编码准则的检查。通过这种方式,希望确保AUTOSAR库的软件质量,其中包含用于教学、学生自我评估以及研究课题的应用程序。例如,我们正在使用这些评估层面,对研究示范车Yellow Car 进行持续测试,其中包括3个符合AUTOSAR的ECU。在汽车软件课程教学方面,最重要的应用之一是灯光控制,它管理着汽车的不同灯光(如内部、外部)。灯光控制的主要功能被映射到一个ECU,由11个软件组件组成,共有48个端口。AUTOSAR应用之间的联系评估了AUTOSAR规格化的配置文件,称为系统描述。就灯光控制而言,已经检查了3429行的配置和262行的代码。为了演示各层面检查的目的,想象一下图5中的情景:在当前的开发中,应该集成两个新的端口。这些端口能够集成一个活跃的信号,代表对其他ECU的可用性。被指定的开发者已经在软件架构中实现了这些端口,但它们在RTE中没有端点。因此,该评估将显示96%的符合性(见公式2)。但是,我们对连接端口的测试配置将100%定义为严格的要求。因此,程序员需要解决断
开连接的端口。这个检查乍一看可能是微不足道的,但是因为即使没有连接的端口,代码也是可编译的,它是在开发后期才会被检测到的方面,从而产生不必要的额外费用。此外,根据经验,这种错误经常发生,特别是对AUTOSAR新手来说。除此之外,ASTAS目前的检查还分析了端口的更多属性,而不仅仅是连接。
由于我们有两个端口,一个具有require属性,第二个端口具有provid属性,ASTAS建议用户用一个接口连接这两个端口。为此,用户可以选择发送者-接收器和客户端-服务器的通信原则。图6显示了程序员批准后进行的修正。在这种情况下,修正改变了系统描述,这是一个正式的标准化AUTOSAR配置文件。一个发送者-接收者接口已经创建,并被分配给两个新的端口。之后,在集成的商业工具链中触发RTE生成,以创建RTE端点。
图 6.  系统描述中对架构中断开的端口的更正
图7显示了在AUTOSAR项目中通过采用自动修正建议所能实现的改进。左边的条形图代表了在引入建议的静态分析之前的学生项目的CL。
图 7.  通过使用拟议的AUTOSAR特定静态测试改善CL

右边的条形图显示了运行静态分析后的CL值。可以看出,在开发过程中,不同架构层的组合获得了最大的改善。这一阶段对学生来说往往是一个挑战,因为它需要对整个标准有深刻的了解,包括其方法和异质的AUTOSAR工具链。


V.结论和未来的工作

本文提出的测试策略促进了AUTOSAR项目的发展。程序员可以通过AUTOSAR特定的静态分析来支持配置和C代码,而一般静态分析工具只支持C代码。静态分析涵盖了系统架构的所有架构层,并且独立于正在使用的AUTOSAR版本和工具链。使用建议的方法,通过提高学生AUTOSAR项目的质量来改善应用程序的可重复使用性。此外,该静态分析通过对AUTOSAR标准的解释和参考,帮助学习者了解软件质量的不同方面,这些问题在架构中都有显示。因此,ASTAS的静态分析是汽车软件工程硕士研究课程中的一个重要教学部分,特别是从电子学习的角度来看。
在未来,希望将这一概念进一步发展到自我学习和自我评估的方向,其中个人统计变得更加重要。例如,我们通过直接向学习者展示一致性值和水平随时间的变化来探索对学习者动机的影响。


参考文献:

[1]  S. Mathur and S. Malik, “Advancements in the v-model,” International Journal of Computer Applications, vol. 1, no. 12, 2010.

[2]  B. Hardung, T. Kölzow, and A. Krüger, “Reuse of software in distributed embedded  automotive  systems,”  in  Proceedings  of  the  fourth  ACM international conference on Embedded software - EMSOFT '04.    ACM Press, 2004.

[3]  K. Juhnke, M. Tichy, and F. Houdek, “Challenges concerning test case specifications in automotive  software testing: assessment of frequency and criticality,” Software Quality Journal, nov 2020.

[4]  N. Englisch, R. Bergelt,  and W. Hardt,  “An Educational Platform  for Automotive Software Development and Test,” in 2020 IEEE 32nd Confer- ence on Software Engineering Education and Training (CSEE&T).  IEEE, nov 2020.

[5]  A. Leitner, R. Mader, C. Kreiner, C. Steger, and R. Weiss, “A development methodology for variant-rich automotive software architectures,” e  &  i Elektrotechnik und Informationstechnik, vol. 128, pp. 222–227, 2011.

[6]  P. Louridas, “Static code analysis,” IEEE Software, vol. 23, no. 4, pp.58–61, jul 2006.

[7]  A. Imparato, R. R. Maietta, S. Scala, and V. Vacca, “A comparative study of static analysis tools for AUTOSAR automotive software components development,” in 2017 IEEE International Symposium on Software Reli- ability Engineering Workshops (ISSREW).   IEEE, oct 2017.

[8]  I.  Gomes,  P.  Morgado,  T.  Gomes,  and  R.  Moreira,  “An  overview  on the static code analysis approach insoftware development,” Faculdade de Engenharia da Universidade do Porto, Tech. Rep., 2009.

[9]  R.  van  Megen  and  D.  B.  Meyerhoff,  “Costs  and  benefits  of  early defect  detection:  experiences  from  developing  client  server  and  host applications,” Software Quality Journal, vol. 4, pp. 247–256, dec 1995.

[10]  J. Westland, “The cost of errors in software development: evidence from industry,” Journal of Systems and Software, vol. 62, pp. 1–9, 2002.

[11]  P. Vitharana, “Defect propagation at the project-level: results and a post-hoc analysis on inspection efficiency,” Empirical Software Engineering, vol. 22, no. 1, pp. 57–79, nov 2015.

[12]  M. Kulenovic and D. Donko, “A survey of static code analysis methods for security vulnerabilities detection,” in 2014 37th International  Con- vention on Information and Communication Technology, Electronics and Microelectronics (MIPRO).   IEEE, may 2014.

[13]  M. Courrier, H. Clergeau, A. Calvy, P. Favrais, and M. Lecat, “Autosar

bsw  in  real  life:  A  summary  of  the  last  years  starting  and  putting projects into production,” in Embedded RealTime Software and Systems (ERTS2012), Toulouse, France, Feb. 2012.

[14]  N. Englisch, R. Mittag, F. Hänchen, O. Khan, A. Masrur, and W. Hardt,

“Efficient Static Testing of AUTOSAR Software supported by an auto- matically created Knowledge Base,” in Proceedings of the 7th Conference on Simulation and Testing for Vehicle Technology, May 2016, pp. 87–97.

[15]  H.  Venkitachalam,  K.  A.  Powale,  C.  Granrath,  and  J.  Richenhagen,

“Automated Continuous Evaluation of AUTOSAR Software Architecture for Complex Powertrain Systems,” in INFORMATIK 2017, 15. GI Work- shop Automotive  Software Engineering, M. Eibl and M. Gaedke, Eds. Gesellschaft für Informatik, Bonn, 2017, pp. 1563– 1574.

[16]  D. Diekhoff, “AUTOSAR Basic Software for Complex Control Units,” in

Proceedings of the Conference on Design, Automation and Test in Europe, ser. DATE ’10.   3001 Leuven, Belgium, Belgium: European Design and Automation Association, 2010, pp. 263–266.

[17]  N. Englisch, A. Heller, U. Tudevdagva, J. Tonndorf-Martini, L. Gaitzsch,

and  W.  Hardt,  “Adaptive  Learning  System  in  Automotive  Software Engineering,” in Proceedings  of  the  27th International  Conference  on Software, Telecommunications and Computer Networks (SoftCOM), 2019.

[18]  N.  Englisch,  F.  Hänchen,  F.  Ullmann,  A.  Masrur,  and  W.  Hardt,

“Application-Driven Evaluation of AUTOSAR Basic Software on Modern ECUs,” in Proceedings of the 13th IEEE/IFIP International Conference on Embedded and Ubiquitous Computing (EUC), October 2015, pp. 60– 67.

[19]  N. Englisch, O. Khan, R. Mittag, F. Hänchen, A. Heller, and W. Hardt,

“YellowCar Automotive MultiECU Demonstrator Platform,” in 15.  GI Workshop Automotive Software Engineering, 2017, pp. 1517– 1522.


END

分享不易,恳请点个【👍】和【在看】

智能汽车开发者平台 分享汽车最新前言技术解读,行业分析,与授权行业资料分享平台。
评论 (0)
  • ## DL/T645-2007* 帧格式:* 帧起始字符:68H* 地址域:A0 A1 A2 A3 A4 A5* 帧起始字符:68H* 控制码:1字节* 主站:* 13H:请求读电能表通信地址* 11H:请求读电能表数据* 1CH:请求跳闸、合闸* 从站:* 91H:正常应答读电能表* 9CH:正常应答跳闸、合闸* 数据域长度:1字节* 数据域:DI0 DI1 DI2 DI3* 发送方:每字节+33H* 接收方:每字节-33H* 数据标识:* 电能量* 最大需量及发生时间* 变量* 事件记录*
    四毛打印店 2025-04-09 10:53 51浏览
  •   卫星图像智能测绘系统:地理空间数据处理的创新引擎   卫星图像智能测绘系统作为融合卫星遥感、地理信息系统(GIS)、人工智能(AI)以及大数据分析等前沿技术的综合性平台,致力于达成高精度、高效率的地理空间数据采集、处理与应用目标。借助自动化、智能化的技术路径,该系统为国土资源管理、城市规划、灾害监测、环境保护等诸多领域输送关键数据支撑。   应用案例   目前,已有多个卫星图像智能测绘系统在实际应用中取得了显著成效。例如,北京华盛恒辉北京五木恒润卫星图像智能测绘系统。这些成功案例为卫星
    华盛恒辉l58ll334744 2025-04-08 16:19 77浏览
  •   工业自动化领域电磁兼容与接地系统深度剖析   一、电磁兼容(EMC)基础认知   定义及关键意义   电磁兼容性(EMC),指的是设备或者系统在既定的电磁环境里,不但能按预期功能正常运转,而且不会对周边其他设备或系统造成难以承受的电磁干扰。在工业自动化不断发展的当下,大功率电机、变频器等设备被大量应用,现场总线、工业网络等技术也日益普及,致使工业自动化系统所处的电磁环境变得愈发复杂,电磁兼容(EMC)问题也越发严峻。   ​电磁兼容三大核心要素   屏蔽:屏蔽旨在切断电磁波的传播路
    北京华盛恒辉软件开发 2025-04-07 22:55 238浏览
  • 在人工智能技术飞速发展的今天,语音交互正以颠覆性的方式重塑我们的生活体验。WTK6900系列语音识别芯片凭借其离线高性能、抗噪远场识别、毫秒级响应的核心优势,为智能家居领域注入全新活力。以智能风扇为起点,我们开启一场“解放双手”的科技革命,让每一缕凉风都随“声”而至。一、核心技术:精准识别,无惧环境挑战自适应降噪,听懂你的每一句话WTK6900系列芯片搭载前沿信号处理技术,通过自适应降噪算法,可智能过滤环境噪声干扰。无论是家中电视声、户外虫鸣声,还是厨房烹饪的嘈杂声,芯片均能精准提取有效指令,识
    广州唯创电子 2025-04-08 08:40 185浏览
  •     根据 IEC术语,瞬态过电压是指持续时间几个毫秒及以下的过高电压,通常是以高阻尼(快速衰减)形式出现,波形可以是振荡的,也可以是非振荡的。    瞬态过电压的成因和机理,IEC 60664-1给出了以下四种:    1. 自然放电,最典型的例子是雷击,感应到电力线路上,并通过电网配电系统传输,抵达用户端;        2. 电网中非特定感性负载通断。例如热处理工厂、机加工工厂对
    电子知识打边炉 2025-04-07 22:59 142浏览
  •   物质扩散与污染物监测系统:环境守护的关键拼图   一、物质扩散原理剖析   物质扩散,本质上是物质在浓度梯度、温度梯度或者压力梯度等驱动力的作用下,从高浓度区域向低浓度区域迁移的过程。在环境科学范畴,物质扩散作为污染物在大气、水体以及土壤中迁移的关键机制,对污染物的分布态势、浓度动态变化以及环境风险程度有着直接且重大的影响。   应用案例   目前,已有多个物质扩散与污染物监测系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润物质扩散与污染物监测系统。这些成功案例为物质
    华盛恒辉l58ll334744 2025-04-09 11:24 53浏览
  • 文/郭楚妤编辑/cc孙聪颖‍伴随贸易全球化的持续深入,跨境电商迎来蓬勃发展期,物流行业 “出海” 成为不可阻挡的必然趋势。加之国内快递市场渐趋饱和,存量竞争愈发激烈。在此背景下,国内头部快递企业为突破发展瓶颈,寻求新的增长曲线,纷纷将战略目光投向海外市场。2024 年,堪称中国物流企业出海进程中的关键节点,众多企业纷纷扬帆起航,开启海外拓展之旅。然而,在一片向好的行业发展表象下,部分跨境物流企业的经营状况却不容乐观。它们受困于激烈的市场竞争、不断攀升的运营成本,以及复杂的国际物流环境,陷入了微利
    华尔街科技眼 2025-04-09 15:15 74浏览
  • 文/Leon编辑/侯煜‍就在小米SU7因高速交通事故、智驾性能受到质疑的时候,另一家中国领先的智驾解决方案供应商华为,低调地进行了一场重大人事变动。(详情见:雷军熬过黑夜,寄望小米SU7成为及时雨)4月4日上午,有网友发现余承东的职务发生了变化,华为官网、其个人微博认证信息为“常务董事,终端BG董事长”,不再包括“智能汽车解决方案BU董事长”。余承东的确不再兼任华为车BU董事长,但并非完全脱离华为的汽车业务,而是聚焦鸿蒙智行。据悉,华为方面寻求将车BU独立出去,但鸿蒙智行仍留在华为终端BG部门。
    华尔街科技眼 2025-04-09 15:28 71浏览
  •   卫星图像智能测绘系统全面解析   一、系统概述   卫星图像智能测绘系统是基于卫星遥感技术、图像处理算法与人工智能(AI)技术的综合应用平台,旨在实现高精度、高效率的地理空间数据获取、处理与分析。该系统通过融合多源卫星数据(如光学、雷达、高光谱等),结合AI驱动的智能算法,实现自动化、智能化的测绘流程,广泛应用于城市规划、自然资源调查、灾害监测等领域。   应用案例   目前,已有多个卫星图像智能测绘系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润卫星图像智能测绘系统
    华盛恒辉l58ll334744 2025-04-08 15:04 92浏览
  •   物质扩散与污染物监测系统软件:多领域环境守护的智能中枢   北京华盛恒辉物质扩散与污染物监测系统软件,作为一款融合了物质扩散模拟、污染物监测、数据分析以及可视化等多元功能的综合性工具,致力于为环境科学、公共安全、工业生产等诸多领域给予强有力的技术支撑。接下来,将从功能特性、应用场景、技术实现途径、未来发展趋势等多个维度对这类软件展开详尽介绍。   应用案例   目前,已有多个物质扩散与污染物监测系统在实际应用中取得了显著成效。例如,北京华盛恒辉和北京五木恒润物质扩散与污染物监测系统。这
    华盛恒辉l58ll334744 2025-04-09 14:54 91浏览
  • HDMI从2.1版本开始采用FRL传输模式,和2.0及之前的版本不同。两者在物理层信号上有所区别,这就需要在一些2.1版本的电路设计上增加匹配电路,使得2.1版本的电路能够向下兼容2.0及之前版本。2.1版本的信号特性下面截取自2.1版本规范定义,可以看到2.1版本支持直流耦合和交流耦合,其共模电压和AVCC相关,信号摆幅在400mV-1200mV2.0及之前版本的信号特性HDMI2.0及之前版本采用TMDS信号物理层,其结构和参数如下:兼容设计根据以上规范定义,可以看出TMDS信号的共模电压范
    durid 2025-04-08 19:01 157浏览
  • 在万物互联时代,智能化安防需求持续升级,传统报警系统已难以满足实时性、可靠性与安全性并重的要求。WT2003H-16S低功耗语音芯片方案,以4G实时音频传输、超低功耗设计、端云加密交互为核心,重新定义智能报警设备的性能边界,为家庭、工业、公共安防等领域提供高效、稳定的安全守护。一、技术内核:五大核心突破,构建全场景安防基座1. 双模音频传输,灵活应对复杂场景实时音频流传输:内置高灵敏度MIC,支持环境音实时采集,通过4G模块直接上传至云端服务器,响应速度低至毫秒级,适用于火灾警报、紧急呼救等需即
    广州唯创电子 2025-04-08 08:59 145浏览
我要评论
0
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦