实际上，关于AUTOSAR的相关问题，也是很多企业经常向飞斯柯罗咨询的内容。在本次网络研讨会中，我们将围绕屏幕上面的问题，并重点解答行业实务人员最为关注的一些核心问题。
接下来，将简要介绍一下飞斯柯罗在AUTOSAR相关领域所具备的能力。
首先，我们对车载电子控制器（ECU）拥有深厚的理解。我们自主开发了面向SDV的下一代控制器软件和硬件，并已成功注册成为全球OEM的Tier 1供应商。
其次，我们拥有强大的网络安全能力和专业的红队（Red Team）。我们已经完成了10个车型的全部控制器漏洞分析，并在约150种控制器上应用了自主开发的安全解决方案。凭借在网络安全方面的专业能力，我们能够在BSW开发过程中充分考虑网络安全因素，从而确保ASW能够稳定、可靠地运行。
最后，我们还拥有丰富的AUTOSAR实战经验以及协作能力。
通过在自研控制器中实际应用AUTOSAR，我们能够深入理解Tier企业在实际项目中的需求。同时，我们也与全球AUTOSAR提供商建立了战略合作伙伴关系。
在本期网络研讨会中，我们将基于飞斯柯罗的成功案例，与大家分享AUTOSAR在实务中的经验与方法。
■ 问题LIST
1. 在SDV时代，控制器开发企业面临的核心课题是什么？
2. 什么是AUTOSAR？
3. AUTOSAR不是只需要应用一种就可以了吗？
4. 如何应用AUTOSAR？有哪些实际应用案例？
5. ASW与BSW开发时需要考虑哪些因素？
6. 为满足网络安全要求，是否必须使用AUTOSAR？
7. 如何高效使用AUTOSAR Authoring Tool？
8. 自动化后，代码变更是否会带来影响？
9. 如何进行验证？
■ 文本 Ver.
1. 在SDV时代，控制器开发企业面临的核心课题是什么？
在SDV时代带来的创新性变革中，我们非常理解各位控制器开发人员所面临的各种挑战。特别是在向SDV转型的过程中，行业正面临着几项重要课题。主要挑战包括以下几个方面。
首先是软件复杂性。在管理不断增加的软件复杂性的同时，确保系统的可靠性和安全性至关重要。
第二是网络安全。为了保护SDV所产生的大量数据，防止网络攻击和个人信息泄露，需要采用强大的加密技术以及安全的数据存储机制。
第三是法规与法律体系。围绕ADAS（高级驾驶辅助系统）等技术，需要建立更加完善的监管体系，同时在责任划分等问题上，也需要政府与产业各方的协同合作。
第四是互操作性与系统集成。要将来自不同供应商的各种软件组件整合为一个协同运作的系统，需要实现标准化，并加强产业之间的协作。
最后是技术发展与成本管理。随着技术的快速发展以及持续的软件更新，企业在适应这些变化的过程中，成本会不断增加，开发复杂度也会随之提升。
而“AUTOSAR”正是在这样的背景下产生的，为了推动软件标准化，提升系统的安全性、性能以及用户体验。
AUTOSAR是AUTomotive Open System Architecture（汽车开放系统架构）的缩写。可以理解为面向汽车产业的一种开放式系统架构。通过这一架构，可以使来自不同供应商的软件和硬件组件实现顺畅协同工作。
AUTOSAR联盟的口号是：“在标准上合作，在实现上竞争”。也就是说，各家汽车制造商不需要各自重复研究基础架构，而是通过合作共同制定优秀的架构和标准化规范。在此基础上按照统一标准进行开发，无论是整车厂还是零部件供应商，都能够从中受益。接下来我们来看一下，AUTOSAR 如何帮助解决刚才提到的那些挑战。
首先，AUTOSAR提供了一个标准化的模块化框架。模块化使各个组件能够在不影响整个系统的情况下，独立进行开发、升级或替换。
在网络安全方面，AUTOSAR定义了安全规范，并通过自动化安全测试工具来检测系统中的漏洞。这些自动化工具还可以通过集成测试确保各控制器之间的交互正常，从而简化开发和测试流程。同时，通过系统验证来确保控制器的可靠性、性能以及安全性。
在法规与合规方面，例如软件更新管理法规（UN R156）相关的要求，AUTOSAR也提供了支持。AUTOSAR提供了OTA更新标准。同时，通过自动化系统来处理更新的分发，并通过验证流程来确认更新的稳定性。
在互操作性与系统集成方面，AUTOSAR通过提供标准化架构，确保来自不同供应商的控制器能够顺畅协同运行。同时，软件组件也可以在多个项目或不同车型之间实现复用。
最后，AUTOSAR还提升了系统的灵活性和可扩展性。通过AUTOSAR，可以更加轻松地集成新的功能和更新，这对于SDV来说尤为重要。同时，AUTOSAR也能够支持车辆日益增加的系统复杂度和数据需求。由此可以实现降低开发成本、加速创新、改善维护与更新效率，并加强各利益相关方之间的协作。
目前，AUTOSAR已经被众多主要汽车制造商和零部件企业所采用。例如重要的AUTOSAR合作伙伴包括BMW、Ford、GM、Toyota、Volkswagen，以及现代/起亚汽车。这些实际应用案例充分证明了AUTOSAR的必要性和有效性。
AUTOSAR的分层结构主要包括 ASW、BSW 和 RTE。ASW（Application Software）是应用软件模块，用于实现发动机控制、制动系统等特定功能。BSW（Basic Software）是基础软件模块，包含硬件抽象、内存管理等功能。RTE（Run-time Environment）即运行时环境，用于管理ASW与BSW之间的数据流。这种结构能够促进软件开发的模块化，并提升系统之间的互操作性。
应用软件（Application SW）为了能够在不依赖具体硬件的情况下实现独立复用，通常会在 VFB（Virtual Functional Bus，虚拟功能总线）上进行设计。当然，Application SW也需要适配AUTOSAR这一新的平台。为了将VFB在实际系统中实现，BSW需要完成大量工作。开发方式也从过去通过键盘手写代码（Hand coding），转变为通过工具进行配置（Configuration）。通常情况下，最基础的AUTOSAR实现大约需要100～200KB的Flash内存。而在高度集成的高级控制器中，一般需要1～4MB的Flash内存。
3. AUTOSAR不是只需要应用一种就可以了吗？
在SDV车辆中，通常会同时应用Classic AUTOSAR和Adaptive AUTOSAR。Classic平台非常适合用于发动机控制、制动系统等需要实时性的传统功能。而Adaptive平台则更适用于ADAS和信息娱乐系统等高性能应用。将这两个平台结合使用，可以为车辆提供更好的可扩展性、灵活性以及面向未来的适应能力，使车辆能够更好地应对新技术的发展。目前，BMW、Volkswagen、现代汽车等制造商都在同时应用这两种AUTOSAR平台。
业界通常会同时应用Classic和Adaptive AUTOSAR，这一点我们已经了解了。那么，在选择AUTOSAR解决方案时，有哪些方面是需要重点考虑的呢？
在选择AUTOSAR解决方案时，首先需要考虑的是MCU的可用性与兼容性，这是一个核心因素。AUTOSAR 解决方案需要在多个方面与目标芯片组保持良好的匹配，例如：包含各类工具和库的工具链（Toolchain）、Authoring工具的用户体验（UX）与使用便利性，以及合规性与技术支持能力。通过这些要素，才能确保开发流程顺畅，并构建稳定且高效的汽车软件系统。
另外一个需要考虑的方面是：为了满足不同汽车制造商的需求和标准，必须对标准架构进行相应的调整。这包括定制化扩展、功能安全与网络安全以及性能优化等内容。通过满足这些要求，制造商既能够遵循行业标准，也能够凭借自身的独特功能在市场中脱颖而出。
目前市场上存在许多AUTOSAR供应商。不同供应商在许可模式、维护条件以及相应价格体系方面都会有所不同，因此建议在采购前进行充分比较。同时，也需要确认购买后是否能够获得培训支持以及工程技术支持。
4. 如何应用AUTOSAR? 有哪些实际应用案例？
首先，目前供应给韩国最大汽车OEM——H公司的大部分控制器，主要采用了Mobilgene AUTOSAR平台。但是，当面向海外汽车OEM，或者面向除H公司之外的韩国OEM时，实际情况是需要采用 ETAS、Vector或Elektrobit等公司的AUTOSAR平台，而不是Mobilgene。
飞斯柯罗在为K公司开发网关控制器时，也曾应用过AUTOSAR平台。在项目初期，由于给定的开发周期非常短，我们也曾考虑过自行开发平台，但综合考虑到“系统运行的稳定性以及市场验证的可靠性”，最终选择采用已经经过验证的AUTOSAR平台。在对不同平台进行比较时，我们主要考虑了开发周期、价格、技术支持是否完善，以及是否包含网关功能等因素。在综合这些条件之后，最终选择了其中一家厂商的方案并进行了应用。
当时根据客户的要求，我们在2个月内完成了开发，并交付了应用AUTOSAR的网关控制器软件。该软件实现了网关的基础功能，包括消息路由（Message Routing）、信号路由（Signal Routing），以及部分诊断功能。
由于AUTOSAR的应用通常需要较高的技术能力，很多人听到仅用2个月就完成AUTOSAR 应用开发都感到非常惊讶。
一般的AUTOSAR开发流程如图所示。
1) 首先，会根据控制器的需求，客户通常会提供CAN DBC文件、诊断CDD文件、需要实现的DTC（故障码） 以及网络相关信息 等基础资料。
2) 接下来，将收到的CAN DBC和诊断CDD导入到AUTOSAR工具中，并利用其他信息在工具中完成Configuration（配置）工作。
3) 当配置完成并保存后，系统会生成 .arxml文件。该文件不仅包含了BSW中设置的配置参数，还包括ASW的软件组织（SW-C）的输入输出信息以及Runnable的调用周期等内容。
4) 接下来，通过BSW Code Generation过程，系统会根据包含BSW配置信息的arxml文件生成BSW代码；通过RTE Code Generation，生成与Runnable调用及ASW软件组件输入输出接口相关的代码。
5) 利用包含ASW信息的arxml文件，还可以使用Matlab等建模工具构建应用逻辑，并生成应用层源代码。
6) 最后，将生成的源代码通过编译工具（Compiler Tool）进行构建，就可以生成用于控制器的固件镜像（Firmware Image）。然后将该镜像下载到目标控制器MCU上进行运行验证。
通过今天的介绍来看，AUTOSAR 的应用似乎对Tier企业来说有很多优势。不过在应用之前也需要进行充分的考虑。大家可能都知道应用AUTOSAR的诸多优势，从开发者的角度来看，最大的优点在于MCAL、BSW、RTE和OS Configuration等大部分代码都是通过Configuration生成的，因此可以显著减少人为编码错误的发生。不过，这也意味着需要进行大量的配置工作。例如，CAN消息、信号以及所需的诊断功能等，通过CAN DBC和诊断CDD文件导入到AUTOSAR工具时，与CAN相关的设置可以在一定程度上自动完成，但除此之外仍需进行大量额外配置。
因此，对于首次接触AUTOSAR的开发者来说，采用AUTOSAR平台可能会感到比较陌生，入门门槛较高，操作也不容易。建议在充分接受培训并积累一定经验后，再进行引入与应用。
5. ASW与BSW开发时需要考虑哪些因素？
在使用AUTOSAR平台进行开发时，最重要的方面是对控制器系统规格、包含MCU的硬件结构的充分理解，以及对系统功能的准确分析、输入输出的定义与设计。其实，这部分即便不使用AUTOSAR平台，也是控制器开发中最基本且最重要的环节。
正如之前提到的，AUTOSAR 的一个重要优势就是软件的可复用性。即便控制器的硬件发生变化，只要该控制器的功能未变且输入输出接口未发生变化，ASW部分就可以在新的硬件上无需修改直接复用。如果控制器的功能和输入输出未发生变化，ASW部分是可以复用的。那么，在进行ASW开发时，需要考虑哪些方面呢？
在开发ASW时，首先需要考虑的事项是控制器各功能的定义，以及针对每个功能所需的输入输出整理，同时明确这些功能应当以什么样的时间周期执行。
当这些内容整理清楚后，无论是使用 Matlab等模型化工具开发，还是通过手动编码，都可以在与BSW独立的虚拟RTE环境中进行ASW开发。待BSW开发完成后，再通过Integration集成过程，即可完成整个系统的构建。
刚才已经简单介绍过RTE，能否再为大家进一步说明一下它的作用呢？
RTE即Run-Time Environment（运行时环境），可以理解为在ASW中各个功能模块（Software Component）之间，以及 软件组件与BSW之间传递数据和信号的一个 Virtual Function Bus（虚拟功能总线）。RTE位于ASW与BSW之间，通过定义它们之间传递的数据，实现了RTE的虚拟化，从而使ASW和BSW能够独立分离开发，互不影响。
从ASW到RTE的讲解非常清晰，帮助大家理解了整体流程。那么，在开发BSW时，需要考虑哪些方面呢？
可能大家在开发BSW时，最头疼、最需要思考的就是各种配置内容了。如果看AUTOSAR的核心BSW，它主要包括System区域、Memory区域、Communication Service区域、HW Abstraction区域，以及被称为 CDD（Complex Driver）的复杂驱动区域。
首先，System Service区域包含 Os、Mcu、BswM、WdgM、Dem、Gpt 等模块，它负责向应用程序和BSW模块提供整个系统通用的服务。在配置和开发时，需要考虑以下各方面内容：
- 首先，在Os模块中，需要配置具有执行周期和优先级的各类Task，是否使用中断及其对应的ISR连接，以及用于互斥（Mutual Exclusive）的资源。
- 在Mcu模块中，需要配置系统运行所需的基础Clock，并设置控制器的运行模式，如Normal、Sleep、Standby等。
- 在BswM模块中，需要配置系统运行相关的模式（Mode），以及在各模式下应执行的 Action List。
- Gpt（General Purpose Timer）模块用于配置系统中使用的各种定时器。
- 接下来，Watchdog模块用于在软件停止运行、超过定义的时间周期，或执行顺序出错等情况下，确保系统能够重新启动，防止系统异常运行。
- 最后，Dem模块（通常与DTC相关）用于在控制器运行中发现异常时，将异常记录到NVRAM，并将运行状态报告给仪表盘或其他显示模块，以便用户可以察觉系统异常。
能否也介绍一下Memory Service和Communication Service部分。在Memory Service区域中，典型的模块是Nvram，它可以在系统关闭再启动后保留数据。主要存储与DTC相关的信息，以及通过诊断读写的数据。所使用的Flash配置需要根据 主芯片（Main Chipset）或Flash规格进行正确设置，同时还需要配置将要存储的数据项。
在Communication Service区域，需要对与CAN相关的通信模块进行配置。如前所述，当将 CAN DBC和诊断CDD导入AUTOSAR工具时，基本的消息或信号配置会在一定程度上自动生成。此外，对于网关而言，需要进行路由配置，这时可能需要在PDU-R模块中对每个Tx和Rx消息进行单独映射。
I/O硬件抽象（Hardware IO Abstraction）区域是用于使用MCU的输入输出端口（如Adc、Dio、Port、Spi、Uart等）的BSW区域，需要对实际硬件引脚进行配置，并根据各引脚的使用用途进行相应设置。
CDD（Complex Driver）是指在AUTOSAR的BSW/MCAL中未提供的服务需要开发者自行实现时的区域。在这个区域，开发者需要自行定义接口并进行实现。由于AUTOSAR并未提供固定接口，因此可以自由定义和实现接口，这部分不需要过于复杂化或担心。
那么，有没有什么方法可以高效地开发ASW和BSW 呢？
由于控制器开发厂商对产品最为熟悉，因此ASW应该由控制器开发厂商通过多种方式自行开发并实现内化，这是比较合适的方法。然而，即便对控制器及硬件非常了解，BSW的开发仍然较为复杂，因为需要配置的内容非常多，单独开发可能难以高效推进。因此，如果与具有AUTOSAR实际开发交付经验、并熟悉多种AUTOSAR工具的专业公司合作，可能会更高效、更快速地完成产品开发。飞斯柯罗不仅使用AUTOSAR开发过产品，也接触过多种AUTOSAR工具。如果在AUTOSAR相关的合作上有需求，请联系飞斯柯罗。
6. 为满足网络安全要求，是否必须使用AUTOSAR？
准确来说，并不是必须的。在AUTOSAR出现之前，就像CAN系统一样，网络安全也已经能够实现并正常运行。不过，AUTOSAR的出现目的是为了提升软件模块复用、提高系统的质量和可靠性，这一点在前面的内容中已经多次说明。网络安全相关功能也可以从同样的角度来理解。
在ASW中，当执行网络安全相关功能时，AUTOSAR的BSW提供了Crypto Service Layer，其中包含 CSM模块。该CSM模块提供了大部分网络安全所需的接口，包括电子签名验证、MAC生成、加密与解密、随机种子生成等。
但是，我们的安全网关需要根据不同证书授予不同的诊断功能，并且只有持有认证证书的设备才能访问诊断端口，从而增强网络安全功能。因此，单靠BSW默认提供的CSM模块无法实现增强网关的全部网络安全功能，我们在Crypto MCAL之上自行实现了CDD_Crypto，将这些增强功能应用于系统中。
通过这种方式，即便MCU发生变化，只要在 MCAL层配置Crypto模块，网络安全模块仍然可以复用。由于这些软件已经经过多次验证，因此可以减少实现和验证所需的时间，这也是一个显著优势。
将AUTOSAR平台及网络安全模块的应用交给像飞斯柯罗这样的专业公司来开发，也是一种可行的方法。飞斯柯罗在这类软件架构上有完善的设计经验，并且已经成功应用于量产。如果在相关方面有任何疑问，欢迎随时联系飞斯柯罗。
7. 如何高效使用 AUTOSAR Authoring Tool？
当然有。我想以自动化作为一种有效方法来说明。正如前面的问题中也提到的，AUTOSAR通常由AUTOSAR解决方案供应商开发并提供的，这被称为AUTOSAR Package。这个AUTOSAR Package中包含了Configuration Tool（也就是Authoring Tool）、BSW以及RTE。
AUTOSAR的一个核心理念就是尽量减少人为错误，也就是尽可能降低由于人工操作带来的失误。为了实现这一点，通常会通过Configuration Tool/Authoring Tool来自动生成代码。因此，Vector的Microsar使用DaVinci，ETAS AUTOSAR使用ISOLAR，Elektrobit的EB Tresos使用EB Tresos Studio，Mobilgene使用Mobilgene C Studio等工具。
像这样，使用AUTOSAR的好处是仅通过配置就能生成经过验证的代码并直接使用，但Configuration Tool的使用并不简单，需要进行非常细致的设置。当这些细致的设置项增多时，在配置过程中可能发生人为错误。而且，在配置过程中，经常需要多次重复类似的配置操作。因此可以说，这是一项高度依赖工具使用熟练度，并且需要投入大量时间和精力的工作。
因此，如果对Configuration进行自动化，可以通过改善可用性降低入门门槛，同时减少人为错误，还可以将重复的配置工作降到最低，最大化开发生产力，并提高最终成果的一致性和可靠性。
目前大多数Authoring工具会对部分配置进行自动化，但对于整个项目级别的配置仍显不足。尤其是在通过复用硬件和软件，将控制器派生到整车或应对其他OEM客户时，如果能实现自动化，仅需对部分内容进行修改，其效果将非常显著。
例如，要完成与诊断DTC相关的整体配置，需要在DEM Service中新增DTC条目，除此之外，还需要对每个DTC代码所需的NVRAM和FEE配置 以及ASW中用于DTC状态监控和事件设置的Port配置进行配置。在Authoring工具中，可以通过导入DEXT文件 在DEM Service中设置DTC条目，但其余的 NVRAM/FEE和ASW Port配置 仍需单独完成，且当DTC条目较多时，需要对每个条目进行重复操作。在此过程中，如果遗漏某些条目或连接错误信息，DTC将无法正常工作。如果对这些配置部分进行自动化，正如前面所提到的，可以最大化时间效率并提升成果的可靠性。
当然会有影响。不过，如果实现了自动化，这些变化是可预测的。因为在进行配置自动化时，我们通常已经验证过其结果。
然而，配置自动化带来的变化，也可能像一般修改一样，产生与预期不同的影响。因此，无论是否自动化，即便是微小的配置修改，也必须对整个控制器功能进行验证。通常我们称这种验证为回归测试（Regression Test）。其目的是确认在修改前能正常运行的功能，修改后是否仍然正常。在软件开发过程中，回归测试是反复进行的。每次软件更新时，如果手动对全部功能进行验证，既不容易，又会消耗大量资源和时间。为了解决这个问题，验证过程也需要自动化。
那么，为了高效地进行重复性测试，通常会采用什么方法呢？
通常会通过HIL（Hardware In The Loop）、SIL（Software In The Loop）等方式，自动执行测试。顾名思义，这是将控制器置于类似实车的虚拟化环境中进行测试。HIL是基于硬件的测试环境，利用各种设备搭建测试环境，并将实际控制器连接进行测试。SIL是通过软件搭建虚拟环境，在这个虚拟化环境中运行软件进行测试。目前，大多数自动化测试仍然通过HIL来实现。不过，由于软件技术和复杂性不断发展，SIL的使用频率也在增加。
飞斯柯罗在开发控制器时，也曾与专业厂商合作搭建HIL环境，同时也有自主开发并使用HIL系统的经验。通过使用HIL，可以为每个测试用例设置所需输入和期望结果，自动执行全部测试用例，并对执行结果进行报告。
总的来说，用一句话回答就是 “自动化”。通常，验证活动并不是只在某个特定阶段、特定环境下进行，而是从初始设计阶段到开发进行中，再到开发完成阶段，都需要进行多样化的验证。并且在每个阶段，验证的目的、预期结果以及使用的工具都各不相同。
在设计阶段，通常会通过审查设计结果的适当性、合理性、一致性和完整性来展开验证活动。从网络安全的角度来看，这包括制定网络安全概念、设定网络安全目标以及生成需求的过程。在这个过程中，也会对产出的结果进行审查，例如是否准确、完整、一致，以确保结果的质量。如果采用模型驱动的设计，还可能通过 MIL（Model In The Loop）进行验证。在实际软件实现阶段，则会进行大量的代码审查、静态验证、动态验证和单元测试等活动。
我们来逐一说明。对于 Code Review（代码审查）活动，既可以以团队或负责人为单位定期/不定期进行，也可以通过引入Gerrit等工具，将代码审查活动强制化。
对于静态验证，通常会使用Coverity等商用工具，并应用MISRA或CERT-C等标准。有时静态验证会集中在开发接近完成的阶段进行，但这样一来，为了修复缺陷而进行的代码修改会发生在开发收尾阶段，可能会影响已实现的功能，效率也不高，因此建议在开发过程中定期进行。
对于动态验证，通常会按照ISO26262中定义的验证方法进行，在工具方面虽然有多种选择，但我们主要使用Vector CAST。以我们为例，动态验证的单元会以白盒测试的方式进行单元测试（Unit Testing），并将语句覆盖率（Statement Coverage）和分支覆盖率（Branch Coverage）等执行目标达到100%。
对于单元测试，通常会以功能或模块为单位进行，验证该单元中预期的功能是否能够正常运行。
在开发接近完成的阶段，会进行集成验证。正如前面提到的，集成验证需要搭建HIL环境，在实际车辆验证之前，先对控制器单元进行充分验证，这样才能最大化实车验证阶段的效率。
为了帮助大家更好理解，举一个我们开发的案例来说明。我们曾开发CGW（Central Gateway），其功能验证大致分为 1）基本功能验证和2）网络安全功能验证两部分。
对于1）基本功能，由于CGW所需的功能在不同车辆或OEM之间差异不大，因此我们与HIL 设备专业厂商合作开发了测试系统并持续使用。我们特别关注的一点是，根据车辆型号变化而不同的CAN信息，自动生成测试用例，并根据这些测试用例自动执行测试，同时自动生成结果报告。
对于2）网络安全功能，由于不同OEM的要求非常具体化（specific），我们专门制作了HIL设备来进行测试，并实现了从测试用例生成、执行到结果报告编写的全流程自动化。
正如大家所感受到的，随着汽车和控制器中软件比重不断增加，谁能够更高效且稳定地进行软件开发，直接关系到生存能力。这也是为什么会选择像AUTOSAR这样标准化、可复用性高的Platform SW的原因。事实上，开发固然重要，但验证活动尤其耗费时间和成本，且需要反复执行，因此如何实现自动化就变得非常关键。
飞斯柯罗最初是一家专注于网络安全的公司，如今也在控制器开发以及控制器软件开发合作方面开展了大量工作。如果大家在软件开发或验证相关问题上有任何疑问，我们也非常乐意与大家交流，并一起寻找解决方案。欢迎随时与我们联系。
飞斯柯罗是韩国领先的汽车网络安全专业企业。我们通过为客户量身定制解决方案，根据客户的实际情况和环境，提供务实的技术突破口，解决复杂的技术问题。
从专用的网络安全控制器SGW，到无需更换芯片即可满足法规要求的HSM安全解决方案，再到支持网络安全持续优化的“一站式运营管理平台”——CSMS门户，飞斯柯罗致力于以务实的方式解决行业面临的困境，立志成为基于SDV（软件定义车辆）的未来移动出行产业中的重要参与者。我们的团队由汽车电子控制系统开发专家和白帽黑客组成，具备卓越的专业实力。
