2022-01-09点击量：149

近年来，随着移动互联产业的兴起，移动应用软件（Application，App）逐渐渗透到社会生活的各个领域，为大众提供精细化场景化服务。在面向细分领域发展的同时，App种类和数量呈爆发式增长，软件开发工具包（SoftwareDevelopmentKit，SDK）被广泛集成、应用，为日益丰富的App功能、服务提供了技术上的解决方案。数字经济时代下，移动应用场景迅速扩展，SDK逐步成为移动业务价值拓展的重要组成部分。然而，由于SDK具有泛用性、灵活性等特点，一旦出现安全问题，不仅自身业务受到直接影响，也会威胁到集成SDK的App业务安全和数据安全，严重的情况下甚至可能影响移动应用系统生态安全。随着安全形势不断变化，SDK的安全合规问题已经进入各方视野，SDK可能存在的安全漏洞、恶意行为，以及隐藏在App背后不透明地收集使用个人信息等问题逐渐成为各方关注的焦点问题。报告从场景分析、数据统计、政策标准方面分享了SDK行业发展现状，对SDK行业面临的合规风险、安全风险进行了分析，面向SDK及App开发者提出了安全措施建议，并从实践角度分享案例和经验，为促进SDK行业生态的健康发展提供参考。SDK通常无法独立展示前台页面，其告知行为往往需要借助宿主App传达给用户，但由于部分SDK未向App告知或完整告知自身所收集的个人信息，或者SDK公开了收集使用规则但App未向用户明示等原因，使得用户对SDK收集个人信息行为毫无感知。还有部分SDK未经用户同意，私自调用权限隐蔽收集个人信息，私自通过自启动、关联启动等方式收集个人信息。SDK未经用户同意收集个人信息，不仅增加了自身的违规风险，也会为宿主App制定收集使用规则，全面列举收集使用的个人信息带来障碍。SDK实际收集的用户个人信息超出公开文档所声明的系统权限和个人信息。此类行为主要表现为SDK收集与其所提供服务无关的个人信息，强制申请非必要的权限，私自调用权限隐蔽收集个人信息，私自通过自启动、关联启动等方式收集个人信息，自动收集个人信息的频度和时机不合理等。例如，部分SDK会收集非必要的设备信息、网络环境信息，读取用户设备已安装应用程序列表，甚至超范围收集用户通讯录、通话记录、地理位置等敏感个人信息。SDK帮助App开发者实现登录、支付、推送、数据统计分析等业务功能，存在未经用户授权使用个人信息的合规风险。一方面，SDK收集的个人信息可能涉及个人身份、财产等敏感信息，还可以通过App权限情况获得位置信息、短信信息、鉴权信息等，如果未经用户授权使用，有可能严重损害用户权益。另一方面，第三方SDK可能被各行业各类型的App集成，从而汇集多款App用户个人信息，一旦相关信息被用于实施诈骗、社会工程攻击等违法行为，其危害程度较单个App数据滥用事件更加严重。一方面，部分SDK存在明文传输用户电话号码、设备MAC地址等个人信息，或者私自向其他应用或服务器发送、共享用户个人信息的情况，可能被宿主App或本地恶意程序截获，导致用户个人信息泄露。另一方面，在未经用户同意的情况下，SDK有可能采取加密等方式私自传输收集的个人信息，如果SDK收集使用个人信息行为及相关信息未完全向宿主App告知，会为宿主App带来额外的合规风险。目前许多App与SDK通过开放平台在线签署开发者服务协议来约定权利义务，然而开发者服务协议通常缺少专门约束数据安全的规定，同时App针对SDK收集个人信息行为进行技术检测存在一定难度，使得App对嵌入的SDK收集使用个人信息情况难以完全掌控，集成第三方SDK时容易引入个人信息合规风险。服务提供方应如何合法、合规地收集、保存、使用个人信息，App如何对共享给SDK的个人信息、双方权利义务及第三方SDK收集使用个人信息情况等加强管理监督，正逐渐成为移动应用领域亟待解决的问题。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想在长沙参加影视动漫培训的学生有所帮助。更多课程信息可关注培训无忧网电脑IT培训频道或添加老师微信：15033336050...

2022-01-09点击量：136

面向服务的架构SOA的出现可以打破车内静态交互模型，并且建立功能灵活治理的系统架构。确保新增功能的实现可以与车辆原有的系统架构、驱动方式、通信方式相匹配。（SOA）总体思路是设计组件模型，将不同的应用功能服务进行拆分，并通过定义恰当的通信接口将相应的服务串联起来。接口定义是独立于实现服务的硬件平台、操作系统和编程语言。确保构建在不同系统中的服务可以以一种统一和通用的方式进行交互。SOA是基于系统的概念，这种系统是由一组服务组成的，其中一个服务可以轮流使用另一个服务，应用程序可以根据各自的需要调用一到多个服务。这一点上，SOA与Autosar的工作方式是一致的，因此，当前自动驾驶系统的开发中往往采用了基于Autosar的SOA设计模式。基于Autosar的SOA软件架构基于SOA开发模式的软件架构（见下图）主要在于通过软件抽象层——运行时环境(RTE)拆分独立于硬件的应用软件（ASW）和面向硬件的基础软件(BSW)。一方面，这个抽象层能够为OEM自动驾驶系统开发特定的、有竞争力的软件应用程序。另一方面，它简化了独立于OEM的基础软件标准化，其中，基础软件进一步分为以下几层，“服务”、“ECU抽象”、“微控制器抽象”。此外，它是ECU软件可扩展性的前提条件。运行时环境RTE是从基础软件中抽象出应用层，并组织它们之间的数据和信息流量。这构成了在应用层面向组件、独立于硬件的软件结构的基础，软件模块可以作为独立的单元存在。例如，下一代自动驾驶系统采用SOA软件模块架构，其所有顶层功能都由底层软件模块实现。这些软件模块共同构成了应用程序。各个软件模块仅直接与RTE通信。因此，无论是在ECU内还是超出ECU边界，都设计了清晰的通信边界。通过这种独立性，可以在不了解使用或计划的硬件情况下开发软件组件，或者更确切地说是在ECU之间分配现有软件模块。基于SOA构建软件设计方法除了基于SOA的软件架构模块设计外，AUTOSAR针对汽车软件开发提出了一套标准化的方法论，构建ECU中的软件模块，将各种ECU集成到具有不同总线系统的车辆通信网络。它定义了通用工件和相关活动，特别是活动的依赖关系。在SOA的设计方法中可以使用AUTOSAR的相关信息，定义了一种具有语义约束的正式数据交换格式，这种数据信息作为标准描述了存储在AUTOSARXML(.arxml)文件中，这种ARXML文件实际是由顶层SOA系统架构设计者通过构建相应的SWC组件接口来生成的。软件组件描述为应用软件提供了标准化的组件模型，系统描述定义了系统上的纯软件层与物理系统架构之间的关系，许多工具使用这些描述来配置和生成AUTOSAR中RTE的基础软件。基于SOA架构的流程设计方法的原理如下图所示。其中各框图表示了带有交叉链接的ECU实例。它描述了网络拓扑、每个通道的通信以及各种ECU上软件模块的分配。基于Autosar的SOA软件架构设计方法除了具备描述汽车行业E/E系统的基本能力外，还有许多方面需要实际交换格式的支持，例如可以通过技术文档（包括规范、定义、技术要求等）、接口需求表等可追溯性来贯穿整个软件生命周期。这种集成的变体管理允许OEM和供应商共同深入到基本的AUTOSAR产品线，并在必要时与其合作伙伴交换相互的信息，对这些变体的共同理解和一致解释是联合开发项目成功合作的关键因素。SOA中的应用程序接口用于确保应用程序模块与RTE进行有效链接。其中，APAutosar并未标准化应用程序的内部功能流程，例如算法，而是将在应用程序之间交换的信息。一方面Autosar使用专用语法将基本接口机制进行了标准化。这种标准化接口规范允许软件设计人员和开发人员独立于任何特定硬件或ECU来开发软件模块，这种软件模块可以在包含其使用的数据类型、单位和缩放因子下进行扩展或重用。另一方面对车辆域主体中应用程序接口的语义、内涵、舒适性、动力传动系、底盘以及乘客和行人保护进行了标准化。重点是广泛引入应用程序的接口规范，以重点突破软件模块的重用和交换。最后，标准化应用程序接口的使用对于应用程序的重用至关重要。系统架构-虚拟功能总线为了开发功能系统架构，AUTOSAR引入了虚拟功能总线的概念——VFB（VirtualFunctionBus）。为了避免误解，应该明确指出：AUTOSAR已经指定了VFB概念。这个概念在市场上可用的各种系统架构工具中实现。VFB允许描述整个系统中应用模块之间的功能交互，此描述独立于实际ECU的架构和实施的网络。通过这种方式，VFB将应用程序从硬件中抽象出来，在这里，软件组件被分配给ECU，在每个ECU中，VFB的功能由RTE和底层基础软件实现。在进一步架构构建过程中，功能系统架构被映射到物理架构上或者说在ECU和网络拓扑上。SOA中将单个应用程序描述为软件组件(SWC)。VFB既提供了它们之间的通信机制，也提供了使用基本软件服务到软件组件的机制，各种机制由所谓的端口表示。SOA软件分层1、应用软件SOA软件架构的层模型将应用软件以软件组件的形式放置在应用层中，可以将软件组件分组为在外部再次充当软件组件的组合。通过这个通用组件概念，可以将软件组件的任何嵌套层次结构实现为一个系统。应用软件可以独立于硬件进行设计和开发。软件组件通过端口进行通信，每个端口代表某种通信机制。应用程序之间通信中最重要的机制是“发送方-接收方”用于由数据发送方发起的通信，以及“客户端-服务器”用于接收方发起的通信。除此之外，还有用于过程控制（外部触发事件）或用于访问某些参数（校准、操作模式、非易失性存储器）的更多端口。每个端口都有一个接口，用于确定要通信的数据类型。AUTOSAR已在编程语言C中定义了端口的精确映射。下图显示了ECU内以及不同ECU中的应用程序之间的通信路径。软件组件在AUTOSAR中由“软件组件模板”做特定描述。除了端口和接口的描述之外，这还包含所谓的内部行为。在AUTOSAR的上下文中，“内部行为”是描述与时间或事件相关的过程控制（事件和调度）相关的组件。这包括“可运行实体”的定义，即底层操作系统可在事件或时间上调度的最小软件实体。需要说明的是，要在组件中明确实现的算法不属于“内部行为”。在实践中，有几种典型的方法来填写或编辑软件组件描述。许多基于模型开发的设计工具如EA、Rapshody等，可以从图形模型中生成软件组件描述，并允许编辑相应的条目。此外，RTE生成器通常允许编辑软件组件描述。对于具有特定硬件要求的应用程序，例如作为依赖于某些传感器或执行器的软件，AUTOSAR提供了所谓的传感器/执行器软件组件，其中可以在软件组件描述中注明此类约束。2、实时运行环境AUTOSAR运行时环境(RTE)从基本软件的任何实现细节和控制设备的硬件中提取应用程序。它表示特定ECU上VFB的运行时实现。RTE提供应用程序之间的通信机制和访问基础软件服务的机制。这还包括为通信提供数据缓冲和排队。RTE的实际程序代码取决于应用程序及其通信、使用的基础软件服务和调度。在实践中，代码是由RTE生成器根据软件组件描述信息创建的。严格来说，RTE是一种“中间件”层技术，它可以通过去中心化网络实现应用层组件的重新定位。3、基础软件基础软件通过RTE为应用程序提供所有系统服务和功能。尽管基本软件的功能对于应用程序来说是必不可少的，但车辆用户通常不会很好地注意到这些功能。随着对硬件的依赖性越来越大，基本软件进一步划分为多个层次：即服务层、ECU抽象层和微控制器抽象层。反过来，每一层都包含代表精确指定功能范围的单独模块。AUTOSAR基础软件总共包含大约80个不同的模块，标准对每个模块都有一个要求和软件规范。其中模块的功能行为及其接口是用C定义的，因此一个模块的两种不同但符合标准的实现可以直接互换。基本软件模块的功能行为参数化及其配置使用与应用程序组件相同的形式描述机制。控制单元基本软件模块的配置描述总结在ECU配置描述中。基于Autosar的SOA服务服务层包括通信服务、诊断协议、存储服务、ECU工作模式管理等系统服务，以及作为独立模块的AUTOSAR操作系统（OS）。AUTOSAROS基于实时系统标准OSEK/VDX，在某些领域得到扩展，但在其他领域也受到限制。它是静态配置和缩放的，并提供基于优先级的实时行为和中断处理。在运行时，可以使用各种用于内存访问或时间行为的保护机制。AUTOSAROS也适用于小型和较低性能的微控制器，同时也支持多核对代码、数据使用和使用多个内存分区，服务的模块是独立于硬件的操作系统。这些系统服务可通过RTE提供给应用程序，应用程序不能直接访问底层的基本软件模块。这是保留提供服务作为其功能的一部分从而访问ECU或微控制器资源。服务模块及其底层模块也称为功能栈，例如FlexRay的通信栈。此类堆栈有时会作为一个大型软件单元来实现和集成，而没有AUTOSAR定义的底层模块结构。虽然这破坏了抽象原则并降低了灵活性，但由于实现的效率和性能可能更高，因此在AUTOSAR中使用函数堆栈进行处理很普遍。硬件抽象服务层主要用于硬件抽象。首先，ECU抽象层将ECU布局（即外围模块如何与微控制器连接）与上层分离。尽管这一层是特定于ECU的，但它独立于微控制器。下一级抽象是由微控制器抽象层实现的，其中包括微控制器特定的驱动程序。例如，这些驱动程序是用于数字输入和输出的I/O驱动程序，或用于将模拟信号转换为数字值的ADC驱动程序。因此，AUTOSAR标准直接支持标准化硬件。复杂驱动层用于处理特殊情况，例如，用于控制具有特殊实时要求或具有特定机电硬件要求的复杂传感器或执行器。此类模块并未标准化为AUTOSAR基本软件模块，因为这里需要汽车制造商或供应商的特定专业知识和知识产权。然而，复杂的驱动程序和标准化的模块必须满足AUTOSAR基础软件中接口机制的要求。基于Autosar的SOA系统配置在AUTOSAR的上下文中，系统是指网络控制单元的组合或集成，其中可能包括车辆的所有ECU。系统配置遵循VFB级功能系统架构的开发。在设计系统配置时，会根据系统的实际物理架构做出决定。这些决定主要与系统拓扑有关，即哪些控制单元可用以及它们如何连接。对于每个控制单元，都有关于处理器架构、处理器容量、内存、接口和外围设备或信号方法的资源描述。网络拓扑的描述范围从总线系统到各个通道的通信矩阵。此外，它还包括确定哪个应用软件组件应该在哪个控制单元上运行，所有这些信息都记录在系统描述中。在实践中，这可以通过系统架构设计工具以及VFB设计（也称为系统生成器）或通过基本软件模块的配置工具来完成。系统配置成功需要通过对各个控制单元的进一步配置，最后通过软件集成来完成，每个ECU都是独立的，即如果需要，它可以并行运行。此外，某个控制单元的所有相关信息都被复制到系统配置之外的ECU描述中。这被命名为系统描述的ECU摘录。ECU描述还汇总了每个基本软件模块的配置描述。基本软件配置的许多参数直接来自系统描述或软件组件的描述。其余的自由参数通过使用基本的软件配置工具来设置。在几乎所有基本软件模块的配置步骤之后，属于配置的代码由生成器生成——就像在RTE中一样。应用软件组件的实现是算法和编码的创建，可以与系统配置完全并行完成，因为这一步独立于硬件。最终，基础软件的整个代码连同RTE代码以及所有应用软件组件的代码都集成到每个控制单元的ECU软件中。总结整体上讲，面向服务的SOA架构设计主要包含五个步骤：梳理整车功能、规划SOA架构、服务定义、服务矩阵和ARXML设计、服务验证和仿真；SOA不是一种具体的技术实现，而是一种模板软件架构，而APAUTOSAR则称是一个模板SOA。如何利用Autosar构建好的SOA模型是我们需要特别关注的。本文详细阐述了面向服务的SOA软件设计过程，以Autosar为基础分析软件架构及其设计方法、系统配置、硬件抽象、软件分层等。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想在长沙参加影视动漫培训的学生有所帮助。更多课程信息可关注培训无忧网电脑IT培训频道或添加老师微信：15033336050...

2022-01-09点击量：80

Aspice作为车载软件过程中，关注于功能场景定义（functiondefinition）、架构定义（SystemArchitecture）、系统设计（SystemDesign）、产品设计（ProductDesign）几个大的方面。而下一代智能驾驶系统需要面向服务进行相应的功能设计和开发，实现软硬件解耦。这种开发方式将对整个智能驾驶来说产生颠覆性的影响，比如高性能计算平台HPC包含多核异构处理模式，通过Hypervisor技术实现对硬件抽象，Inter-Core通信技术使多篇和单片多核实现信息互通，计算单元趋于“云计算+中央计算+边缘计算结合等多个方面的变革。如上这些设计原则更多的是基于SOA的架构进行的，这就大大增强了平台的可拓展性，可移植性。当前更多的主机厂选择在智能驾驶中采用SOA的开发模式，这可以更加快速的实现从底层、中间层到应用层的软件开发，且相对较多的软件只要接口定义得当，就可以实现软件本体和功能的迁移，同时可以大大的降低开发周期和成本。对于SOA的设计过程来讲，其服务设计原则包括重用、抽象、封装、协调在内的多个层面。比如对于智能驾驶功能开发而言，如果需要多次用到某一逻辑元素比如车道线等环境信息，则应该将车道线检测模块创建为重用（比如封装到BuildingBlock中），则对该车道线检测源（如不同方位的摄像头）进行调整，则由此对车道线检测产生的任何更新改变都会对后续级联的应用实例产生影响。而上层应用软件端对于底层的如何获取车道线，如何处理的细节也不需要深究，这就是实现模块抽象的整个过程。抽象后的逻辑功能需要保证其体系相类似的功能需要集成到一起，比如自动换道功能的控制逻辑可以在自动激活后调用触发换道相关的规划控制模块进行车控。因此，触发换道的规划决策控制逻辑单元可以完全应用于自动换道模块。系统工程师只需要保证定义的接口适用于触发换道已经发布或预定的数据流即可。对于自动驾驶域控单元负责人而言，应该保持逻辑系统结构之间的协调和重用，包含对公共池中的元素排布，对局部域单元中的逻辑构造，跨域之间的资源或模块调度等。本文将以智能驾驶系统开发设计实例来讲解和分析相应的SOA为基础下的架构设计和软件开发。面向ASPICE流程的SOA软件架构流程适用于SOA架构的ASPICE软件开发过程也是在敏捷开发的模式下进行的系统开发流程。从智能驾驶功能开发层面上讲，基于SOA架构开发模式包括了系统功能、系统架构、软件功能、软件架构几个方面。其中分别由分别称之为产品负责人ProductOwner、功能负责人FunctionOwner、架构负责人ArchitectOwner、子模块负责人ModuleOwner的几个角色共同承担。功能设计是搭建功能架构图和依据产品工程师输入的产品需求定义进行功能分解定义，架构负责人则根据整车架构及功能负责人输入的要素信息制定合适的软硬件架构。这里需要说明的是很多情况下，功能负责人和架构负责人往往是同一个人。模块负责人则是根据功能定义编制相应的系统软硬件模块、零部件软硬件模块以实现上层定义的功能需求。各负责人之间的角色定位将在如下分层流程图中进行详细说明。这里我们仅关注V模型中的与SOA相关度较高的设计开发部分，测试验证部分不在本文中进行详述。其中，各阶段的开发输出功能过程如下：1、项目功能定义项目功能元素（functionelement）包含与顶层设计相关的不同属性，例如车辆类型、预期市场、项目功能以及功能发布计划等。在实际开发中，这类输出一般是产品策划部门或市场部输出的整车功能开发需求或整车装备需求。本文将以开发智能驾驶系统功能中的点对点自动驾驶NOP为例进行详细的分析说明基于SOA的架构设计是如何应用于自动驾驶系统开发的。如下图举例中，表示了实现下一代自动驾驶系统NOP场景定义需求。2、系统架构设计阶段（SystemArchitectureDesign）这个阶段涉及产品能力定义及模块定义。用于描述智能汽车中的用户功能，通过定义相应的函数来指出使用哪些子系统或者零部件具备相应的产品能力（ProductCapabilities，PC）并对其进行相应的实例化来实现此功能。（1）产品能力PC：这种称之为产品能力的模块主要是用于定义想要实现该功能模块的传感器或执行器所具备的能力，这也是位于各个时序图上各个节点的能力描述。通常，该产品能力的定义主要由产品工程师牵头，功能所有者、架构师和模块所有者/设计者的跨职能小组共同决定。（2）产品能力实例化PCInstance：产品能力可以被认为是一种高级服务，一些需要在汽车中实现的功能，但它没有描述应该如何实现。产品能力实例是PC的简单实例化，可以在平台中拥有PC的不同变体。如果需要PC的不同变体实例以及在何处使用不同的实例，则模块所有者负责。系统架构师负责定义系统中定义了产品能力PC的不同类型，并确定哪些PC需要由跨职能团队才能完成。通过将当前定义的PC和其他的需要PC建立依赖关系，我们可以建模一个完整的功能架构，该功能层级的架构无需研究实际的实现机制。这对于定义需要哪些高级服务(PC)以及分配谁（哪个模块）负责实施每个PC非常有帮助。如上过程一般是通过各种图表（包含用例图、序列图、活动图等）来完成的。如下图表示了一种活动图所示意的系统交互方式。由于在定义过程中还建立了与功能之间的连接，因此我们可以使用该模块来规划需要实现PC的顺序，以便我们在每个版本的集成阶段开发出正确的功能。（3）模块及实例ModuleInstance：模块是整个模型甚至整个组织中非常核心的元素。从SOA的架构设计上讲，每个设计的PC都被分配到一个并且只有一个模块（或者称之为函数），该模块负责实现PC，但在整个平台生命周期内维护和发展PC，规划PC的演进步骤，提供路线图等。PC定义的功能在Component中实现，模块实例可以确保在平台中拥有模块的不同变体。系统架构师负责定义系统中存在哪些模块，但模块所有者负责领导模块内的工作，并负责维护和发展模块。模块所有者还负责是否需要模块的不同变体实例以及在何处使用等。同时，模块中的相关参数是在对应构建的系统功能规范中实现定义的。3、软件架构设计阶段软件组件SoftwareComponent：组件是模块的实际设计和实现。组件可以是软件或硬件组件，但在SOA的软件架构中，我们将主要处理软件组件，组件定义了模块需要哪些接口以及提供哪些接口。其中接口将包括SOA架构所要求的服务、属性和事件。在硬件组件上，接口可以是螺孔或电线连接器。软件包SoftwarePackage：软件包是将部署到特定运行环境时的所有软件组件、清单文件等的集合。为了实现面向SOA的架构设计和开发过程，需要重点定义。4、底层驱动设计阶段中央控制单元ECU/处理器Processor/虚拟机VirtualMachine：一个ECU可以由一个或多个处理器组成，一个处理器可以运行一个或多个虚拟机。不必对每个组件进行建模，例如，如果ECU仅包含一个处理器，则仅对ECU进行建模就足够了。可以将各个软件包部署到如上运行时环境中的任何一个。网络及连接器NetworkConnector：定义网络以及连接到它的运行时环境。运行时环境可以由一个或多个网络连接组成，这些网络连接可以是CAN、CANFD、以太网、VLAN、LIN等。严格说来，底层驱动设计应该属于软件架构设计的其中一个部分，面向底层软件设计部分，通常与顶层软件开发团队不是一伙人，且具有较大区别，该开发过程由顶层软件设计人员对底层软件开发人员单独提出需求及建议。一般的需求包括平台软件总体架构及对相关AUTOSAR标准组件和复杂驱动的调度框架设计、开发和集成要求；内存、非易失性存储、任务、中断等等资源和权限分配；上下电流程和管理的设计；系统运行状态监控、异常处理等功能的设计等方面。基于SOA架构模型设计分工基于SOA软件模型架构的设计过程实际是在研究如何在开发流程中进行软硬件解耦。包括构建不同的分层来隔离硬件与软件功能和服务。例如，将自动驾驶相关的传感器和执行器逻辑与应用程序逻辑分开，则能够在中央系统中分配应用程序，同时保持传感器/执行器尽可能的具体。程序之间可以利用SOA的服务模式实现软件包的调用，传感器和执行器也可以作为组件或模组来进行边缘采购，性能则是集中管控，中央系统可以将战略软件进行分开，这就更容易进行软件模块移植和处理。这一过程实际就是在提高上层应用层软件关键功能的复用性，瞄准软硬件功能与逻辑控制分离。这里需要说明的是，软硬件之间的协调和调度是通过中间件来实现。从如下图所示，SOA的架构从下至上分别底层驱动功能管理，物理层功能管理，车辆控制服务，面向用户的应用服务，云端远程管理。底层驱动功能管理：用于实现包含诊断、日志记录、存储管理、驱动管理等相关功能。物理层功能管理：主要是设置I/O接口将原始传感器数据进行输入，同时也是执行到车端的控制单元（如电机、制动卡钳等）；车辆控制服务：车端控制包含上层ADAS发送的执行指令到控制执行器执行该指令的相应ECU（如控制电机的VCU、HCU或ESP），该车辆控制服务是综合考虑了车身稳定性与动力学反馈模型得出的。应用层服务：该层服务就是智能驾驶面向用户级别的顶层开发功能，主要用于实现包含传统的智能驾驶功能，比如HWP、NOP、TJP以及ALC等。云端管理服务：该层服务主要是面向远程监控，远程控制，大数据存储等特殊场景。通常该服务需要基于4G/5G网络进行远程连接。人机交互管理功能：人机交互管理功能一般是针对不同的车型呈现出不同的模式的，因此，这一块一般是独立于SOA的功能架构。SOA通常只涉及底层对车辆控制逻辑，对于平台化车型功能开发来说，这一块是无法为用户所感知的。而HMI的显示设置则是用户能够真切感知和控制的，因此，不同车型肯定是有极大的不同之处。因此，从协议上分析不难看出，SOA内部的网络架构一般是基于以太网为基础的交互方式，采用Some/ip的协议进行通信控制。而如果在平台化车型的开发过程中，HMI这一块的通常仍然按照原始CAN/CANFD信号模式的通信协议进行交互控制。这么做的原因是，智能驾驶的HMI行为比核心应用功能更容易改变，特别是在不同车型开发后期通常会选择不同的显示和交互方式。同时，由于开发核心软件和HMI设计需要不同的能力技能，因此，将HMI功能与其他应用层软件功能分离，为了实现这一点，一般需要使用Model-View-Controller，用户输入由Controller处理，Controller用于解释用户的意图并操作模型。SOA服务实现过程随着车载以太网技术的日益成熟，国内大部分OEM都已经着手SOA的设计工作，并将以太网通信矩阵生成ARXML文件，用于项目前期的网络行为仿真和后期测试验证。对于已经完成架构搭建的SOA来讲，需要将其建模后的成品导入到软件团队进行服务实现。其过程包含：以Some/Ip协议导入ServiceARXML，导入后新增ETH、TCP/IP、Some/IP模块（BSW工程），建立与ServiceHandlerSWC（应用层）中PortInterface连接，为所有ServiceHandlerSWC增加可运行时间，定义WindowsServiceHandlerSWC和FeatureSWC到Simulink/Stateflow。通过符合Autosar的ARXML和Simulink进行交互，将由软件开发工程师继续进行算法设计并自动生成代码。总结本文从SOA软件架构模型的构建角度出发讲解了相应实现过程原理，利用了基于模型、集成式的可视化开发工具PREEvision进行了智能汽车行业及相关领域E/E架构开发并支持以太网SOA的架构开发设计，本文以介绍SOA架构设计模型为基础展示了如何在EnterpriseArchitect中进行SOA建模。同时，以系统工程师的角度说明如何利用EnterpriseArchitect构建SOA系统及软件架构设计、功能设计FunctionDesign和模块设计ModuleDesign。对于SOA在整个智能驾驶系统设计原理有个清晰的把控。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想在长沙参加影视动漫培训的学生有所帮助。更多课程信息可关注培训无忧网电脑IT培训频道或添加老师微信：15033336050...

2022-01-09点击量：115

一背景和问题我个人平时会比较慎用“架构”这个词一方面是觉得业界有很多架构大师和架构模式，而我的认知和实践有限；另一方面是因为这个词看着挺高大上、有点务虚，如果不结合实际场景的具体问题来讨论，容易陷入“PHP是最好的语言”这样的辩论赛中。而不同场景中又有各自的问题，程序员们通过自己的理解和思考、针对实际场景对一些架构模式进行了扩展实践，以此来解决遇到的问题，也会基于同一个模式延伸出一些派生概念。兵无常势，水无常形。所以，我个人的观点是：以要解决的问题为出发点，去讨论我们要采用的架构模式（技术方案）。另外，由于我们是站在很多巨人肩膀上的，讨论时可以站在一些如SOLID等软件设计/开发原则的基础上。写这篇文章，我也是从解决一些问题的目的出发的：最近和团队同学讨论了相关话题，虽然大多数同学在实践上基本一致，但具体到话术、名词概念和具体使用的理解和实践上有些差异（这是很正常的，因为业界对同一个模式的理解和实践也不同）。我结合一些实际编码场景做了一番陈述，为了避免后续重复大费口舌，所以打算写下来，以后有需要直接发文章链接。由于我个人的认知和实践有限，所以也希望能抛（huan）砖（ying）引（lai）玉（pen），让我学到更多。虽然同一个架构模式在不同业务/技术领域的实施会有区别，但同一个团队内应该保持一致性，因为这样有助于日常的codereview、功能模块的交接backup等活动，尤其是有利于使用统一的单测建设方案来保障我们的产品质量。实际问题：我最近在开发商家合并发货的功能，但由于之前基础发货功能的界面和逻辑并不是我开发的，所以我在修改原有代码、支持有非常多细节逻辑的合并发货能力时，就在担心对原有发（zhong）货（yao）能力的影响。而这时候，如果有单测的保障，我就可以更放心地进行功能升级改造了——别说更复杂的合并发货能力了，而这类诉求在复杂的交易场景里很普遍。提炼一下我遇到的具体问题：在由不同开发人员持续迭代、进行功能升级的软件开发活动中，如何保障具有复杂逻辑的商家经营工具的产品质量。软件开发活动是整个流程的核心环节：接收产品和视觉设计需求/变更作为输入，然后输出客户可用的终端产品。而统一的软件开发架构模式，则是我们保障软件开发质量的基础。（这里就不具体展开WHY了）由于讨论的是具体面向客户使用的业务场景，少不了客户操作交互的视图层（View），所以我从MVC开始谈起。二从表现层的MVC谈起虽然我平时比较慎用“架构”这个词，但我平时喜欢随手拍一些建筑物。因为建筑之美，会让我联想到软件的架构也应该有美感，毕竟SoftwareArchitecture这个概念也是起源于Architecture。这时候，架构这个词就会给我一种接地气的感觉：有多少块砖，每块砖做什么用、放到哪里去，这块砖和那块砖怎么黏在一起或互相支撑。当然，由于软件的可移植性、可复用性，从某些角度来讲，软件架构相比建筑架构有其更复杂的地方。MVC诞生至今已经超过40年了（Since1979），10多年前就得到过很广泛的讨论和实践，穿越时空到今天肯定有其反脆弱性和内在核心价值。虽然如今乍看起来好像已经过气、被讨论过千百遍了，但仍然有很多程序员会有不同理解和看法，或多或少。这是很正常的，上面也提到了部分原因，这里具体再展开下。1MVC在经典三层架构里的位置MVC是一种通用架构模式早期PC时代应用在桌面客户端，后来在Web时代变得流行（我以前写PHP也用过相关MVC框架），如今在移动互联网时代也得到广泛应用。上面这三个场景的应用，都是面向客户的，需要交互表现的。从MVC命名中的View（视图）也可以看出，MVC模式应用在软件系统架构里的表现层。在业界某知名公司的官方文档里，也明确把MVC放在WebPresentationPatterns下。我之所以没有在上图中对M-V-C添加箭头线条，是因为在这一点上，不同程序员也有不同理解和实践。这是第一个需要明确的点：MVC架构模式在多层系统架构里的应用范围。左侧业务表现层-业务服务层-基础服务层是移动端三层架构模式，未涉及到C/S交互；右侧是WebB/S场景的三层架构模式。因为有些应用会比较简单，根本不需要业务服务或基础服务层，纯粹靠一个MVC（或者VC）就能交付出一个Mobile/WebApp；而且在一些业务系统里，Web前端/桌面客户端/移动App也可能会被简化为大前端/大终端表现层；所以可能基于不同信息，不同程序员对此会有不同认知。但随着用户终端应用的重要性和复杂度的提升，已经从简单应用发展到复杂多团队协同的平台型或航母级应用，仅靠一个MVC来完成交付是不合适的。我们也可以反过来想，程序员会把以下代码放在客户端代码的哪一层：对Web引擎的扩展逻辑。通信协议的结构定义，以及相应的socket连接和通信代码。一个业务相关且UI无关的平台开放能力。Crash捕获、卡顿监控、日志埋点等功能实现，比如Android在做APM相关事情时会采用AOP方式，利用ASM、AspectJ等方案来做字节码插桩。……2业界基于MVC模式的不同实践前面提到不同程序员对MVC模式的理解和实践存在差异业界大厂亦然，以下会结合业界一些知名且有影响力的公司在MVC模式上的实践，做进一步的展开讨论。知名公司A知名公司A在指导开发者使用MVC时，推荐下图方式：可以看出在他们的实践上：Controller可以引用View和Model。View可以引用Model。这里的Model倾向于是Passive。同时，他们建议：在强类型视图场景，控制器从模型创建并填充ViewModel实例，该ViewModel实例包含要在该视图上显示的数据。当控制器由于责任过多而变得过于复杂时，也就是业界戏称的“MVCmeansMassiveViewController”，需要将业务逻辑从控制器移出并推入域模型中。知名公司B说到MassiveViewController，知名公司B在移动互联网方兴未艾的时候，推荐下图所示的MVC实践方案：上图呈现出：Controller引用View和Model。Model通过一些松耦合方式来触达Controller，如广播通知、callback等，驱动Controller做出响应。View通过代理模式等方案弱依赖Controller，由Controller对各种用户操作、UI渲染诉求做出响应。而View和Model之间是隔离的，Model变化后对View的更新操作全部由Controller负责。不过相应的官方文档已经被声明是过期文档了，并备注不一定是目前的最佳实践。是的，随着移动互联网蓬勃发展，十年前的“最佳实践”被一路多种挑战——在采用这种方案的开发领域中，如何重构MassiveViewController为LighterViewController已经成为了一个专题。对比和思考A和B的异同点相同点：Model包含所需的数据结构封装，以及相应数据操作的方法定义。即Data+本地或远端的CURD。差异点：在知名公司A给的图中，View可以引用Model，而在知名公司B给的图中则不行。一些问题和思考View有箭头指向Model，这里的引用关系是指什么？是View持有Model.Data数据对象，还是View调用Model.CURD方法。Controller的本意是ControingLogic，那除了ViewController外，是否还可以有其它的XxController，比如DataSourceController、NotificationController？从命名上看，既然ViewController既有View又有Controller，那为什么把它放在C里面，而不放在V里面呢？比如当我们在iOS/Android开发中引入MVVM模式后，ViewController或Activity属于M-VM-V的哪部分呢，代码放在哪个目录下呢？我有类名使用ViewModel后缀就代表我使用MVVM模式了吗？MartinFowler作为《重构:改善既有代码的设计》、《企业应用架构模式》等著作的作者；敏捷软件开发宣言创作者之一；MVVM模式诞生时参考引用的技术专家。MartinFowler给的MVC模式图如下：和上面知名公司A和B的图，又不一样了，不过他这里也是认为View可以引用Model的。MVC和DDDMartinFowler和《领域驱动设计》作者EricEvans也讨论过MVC中Model的设计理念：贫血模型：将Model分为简（pin）单（xue）的Model数据对象，和处理操作数据对象的Service/Manager/BizLogic等。示例：为aPerson修改name，则由CitizenService.changeNameOfPerson(aPerson)这种方式来实现。充血模型：将对应领域的处理逻辑放到领域模型中，使得这个领域模型更饱（chong）满（xue）。示例：aPerson要刷牙，则由aPerson.brushTeeth()来实现。补充：充血模型更有面向对象编程的味道，尤其是搭配交易领域等业务场景，更有体感。不过稍微细想一下，可能就会发现DDD对设计的要求会更高，从而对研发周期和质量保障提出了新的要求，并且可能引起对现有系统的大规模重构。（盒马的DDD实践）也就是说，大到MVC各个模块的依赖引用关系，细到Model中的代码设计方式，业界都有不同的理念和实践。JavaWeb开发领域也对Model的设计产生过非常激烈的讨论。小结先抛开具体模块的代码设计方案，基于以上几种业界大厂或专家的描述，我小结了以下这张图并标注了待解问题：问题一：如何解决MVC中Controller的膨胀臃肿问题？要回答如何解决，需要先思考为什么膨胀。问题二：View能否引用Model？要回答能否引用，需要先定义引用关系是什么。是持有对象，还是调用CURD接口操作对象。又或者这两者没有必要区分，因为持有的对象本身就可能带CURD接口。参考上面相关资料，目前业界有的支持、有的反对。问题三：存在View->Model，那么是否可以反过来存在Model->View？和问题二在描述上相反但又有关联，如果对问题再进一步提问的话：使用->引用关系，是为了解决什么问题？使用->引用关系，会产生什么问题？如同文章开头所说，以上问题需要结合具体场景来展开（见实际案例结合），尽量从务虚到务实。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想在长沙参加影视动漫培训的学生有所帮助。更多课程信息可关注培训无忧网电脑IT培训频道或添加老师微信：15033336050...

2022-01-09点击量：128

如今软件已经是大多数公司的主要组成部分之一，它被整合到所有主要系统中，从金融机构到农业生产，再到客户服务和工业领域。软件开发者已经成了最受欢迎的职业之一，事实上，用几个人和几台计算机就能完成高影响的项目是可能的，这使得这个领域吸引了所有那些有绝妙想法并想为他们开发软件的人。幸运的是，今天我们有了互联网，这个无限的知识来源，成为一名软件开发人员完全可以通过自学。重要的是要了解从哪里开始，什么是必要的基础，根据我的个人经验，编程更多的是一种激情，而不是一份工作，这条道路充满了障碍和终点，所以重要的是慢慢来，不断攻克难关，一步步走向成功。作为工匠的软件开发人员研究表明，与艺术家在创作阶段相比，编程是一种需要更多大脑容量的活动。很多时候，当我需要做一些困难或复杂部分的编程时，我经常需要音乐和电脑进入状态，这样我才能解锁我的创造力，事实上，这个世界需要二者兼备，大多数时候，软件开发人员等同于工匠，这意味着必须完成从a到Z的工作过程，为自己的风格选择负责。编程语言一个人学习的第一种语言有点像他们的母语，你将越来越多的减轻读写，如果您想要深化应用程序的世界，我推荐C或Java，它们是在现实工作中最常用的编程语言，另一方面，如果你对数据科学或者网络安全感兴趣，我建议学习Python，Python学习起来非常简单，但是由于它是一门高级语言，你可能会忽略一些概念关注基础知识软件开发在大多数时候是一项非常有创造性的工作，但如果一直有没能解决的Bug存在，那它也可能是乏味的，对于这一点，在我看来，无论你有什么编程经验，以下方法都值得你学习：CI/CD、DevOps、软件设计、测试、重构等，它们是一组工具、技术和标准，如果使用得当，任何人都能读懂你的代码，它们很重要，因为它们让你能够更快地发现并修复Bug。。如果项目是中等规模和/或团队由3个以上的人组成，那么几乎必须使用这整个系列的技术。不管使用哪种编程语言，了解这些工具以最大化工作效率是很重要的。一点一滴地积累知识很多时候，有太多的东西需要学习，有很多工具可以做类似的事情，因此在开发软件时，选择何种工具经常会碰到困难，这一切的原因都在于学习的不够，带着让你开始编程的激情学习，了解自己的优势和局限是很重要的，例如，你还不是很熟悉对象，那么专注于对象的设计或者一开始就想要创建一个完美的GUI是没有用的。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想在长沙参加影视动漫培训的学生有所帮助。更多课程信息可关注培训无忧网电脑IT培训频道或添加老师微信：15033336050...

2022-01-03点击量：179

在Linux学习结束后，就到了每个人都期待的找工作环节了，那么学完Linux后有哪些职位可以选择？1、IDC机房运维：工作简单，薪资较低，工作内容主要包括：主机监控、信息统计、硬件维护、系统维护，网络维护，比如对托管设备进行日常的巡检、故障记录，协助客户对IDC机房设备进行维护等，很多IDC机房运维在后期都转型做销售岗，也有不少人考了证书，转到大公司做运维了，总而言之，是一个钱少活杂上升渠道小的岗位。2、DevOps运维：是一种方法论，包含一系列的基本原则和实践，目前所有的工具或者说工具链都只是为了对这样的实践提供支持而已，所以这个岗位，都是要求在自动化运维的基础上会一些DevOps工具链而已。3、桌面运维：桌面运维目前属于外包的较多，有专门的公司招聘应届生去培训1-2个月，需要的技能不是很多，但沟通能力很重要，如果不努力提升自己，被替代的可能性也会很大，桌面运维看重学历，要求本科学历的越来越多，对英语的要求也越来越高。4、监控运维：进入这个职位的要求还是有点高的，基本和公司网络管理员的要求差不多，负责监控一些公司网络、服务器、服务的运行是否正常，当运行不正常的情况下，会有相应的报警，需要分析一下报警的情况并汇报给对应的工程师处理，监控工具常用的有Zabbix、Cacti、Nagios、Open-Falcon5、系统运维&自动化运维：两个类似，自动化运维是在系统运维的基础上又加了一些自动化工具，如ansible、saltstack、shell脚本，系统运维到自动化运维，是传统运维向智能运维的过渡，一般情况下，需要会一些常见的ELK，jenkins、gitlab、docker等工具。6、大数据运维：是在系统运维的基础上衍生出的一种，与系统运维不同的是，大数据运维更多的是在维护大数据生态下的产品，比如常见的有Hadoop、Hbase、Spark、Kafka、Redis等，进行日常的集群管理和故障处理以及容量管理。本文由培训无忧网达内IT教育专属课程顾问老师整理发布，更多相关课程请关注培训无忧网程序开发培训或添加老师微信：15033336050...

2021-10-30点击量：393

1、Activity生命周期Android中有四大组件，但Activity是最常用的，练掌握Android的生命周期是必须的。其实生命周期就是记住Activity的那些方法在什么时候被系统调用，这样才可以把对应的逻辑代码写到合适的方法内部去。2、界面开发技术界面开发是一种基本的技术，几乎所有的程序里面都需要用到。在Android开发中界面开发分为3种：1)使用xml文件布局使用xml首先对于界面进行布局，然后在Activity里面进行引用是最常见的应用软件开发技术，这种方式使用的最大，需要学习的内容也最多。学习时需要熟悉：a)五种Layout布局深刻理解五种布局组织控件的方式是一个基本的基础，这样你才可以在实际的界面中灵活的使用每种布局结构，构造出需要的界面。b)常用控件控件有很多，至少要知道每种控件是做什么的，至于里面的特定参数和方法可以学要的时候再去查c)界面美化系统的控件很多时候无法满足要求，需要通过添加背景更换图片等进行美化，要熟悉每种控件如何去美化。掌握了上面的内容，通过布局的嵌套就可以制作出各种界面，如果在熟悉include的使用就可以减少xml的重复，方便后期的修改和维护了。2)使用代码动态创建有些时候需要动态的创建一些布局和控件，这个就需要使用LayoutInflater去创建一些动态的界面了。3)自己绘制界面游戏中常用，继承SurfaceView自己绘制。3、数据存储技术Android中的数据存储方式有3种：1)SharedPrefereneces存储对于简单的数据可以使用该方式存储，以键值对的方式存储一些基本的数据。2)文件存储将数据以文件的形式存储，可以是手机自身的存储也可以是SD卡，文件的数据格式自己定义。3)SQLite数据库存储使用标准SQL语句进行操作，复杂数据的首选。4、网络编程Android程序需要联网，所以网络编程也是必须的，一般的公司都会封装有自己的联网结构，但是基本的联网还是要熟悉。1)HTTP联网使用Http联网+Json数据格式是现在很多客户端的首选。2)Socket联网对于手机的系统功能，如拨打电话、发送短信、读取系统参数等则可以根据需要再学习。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想在长沙参加安卓软件开发培训的学生有所帮助。更多课程信息可关注培训无忧网电脑IT培训频道或添加老师微信：15033336050...

2021-10-30点击量：405

建立一个Android应用程序可以归结为两个主要技能/语言：Java和Android系统。Java是Android的通用编程语言，但是Android还包括学习用于app界面设计的XML语言，学习Android概念，以及从Java编程角度运用这些概念。学了Java和XML之后，再用Android理念将两者连接起来。对于一个初学者，我的建议是一定要学Java。别想什么捷径，Java是必须的。另外，我推荐YouTube上的视频教程来学习如何安装Eclipse（用于Java开发的集成开发环境）和Java开发工具包（JDK）的基本方法。这也有助于理解Java开发的基本方法，例如循环语句和if语句。不过在打好了这些基础之后，我强烈建议各位可以将YouTube视频教程抛弃了，转而投向书籍和系列讲座的怀抱。YouTube的教程往往并不会着重讲述某些很重要的概念，而这些概念我觉得对于我们想要开发Android应用的程序员来说，其重要性是100%的。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想在长沙参加安卓软件开发培训的学生有所帮助。更多课程信息可关注培训无忧网电脑IT培训频道或添加老师微信：15033336050...