每年1月举行的美国CES电子消费大展，已成为各大车厂展示最新汽车技术和未来汽车的主舞台，但是今年展览很不一样，除了各大车厂大秀软件肌肉，第一次有车厂公开说，要把IT圈红火的容器（Container）技术带来汽车。
尽管在IT领域，容器技术发展已相当成熟，为应对汽车软件化风潮，车界近几年出现不少关于汽车软件容器化的讨论，大多只限于开发或测试阶段导入，还没有真正在汽车内部环境使用。所以，当大众要让汽车支持容器技术的消息一出，格外引人瞩目。
其实早在多年前，奔驰汽车就提出要用容器驱动汽车的概念，但当时还无法实现，现在大众抢先一步完成，甚至大众不是构想，而是已经开始实做。
大众汽车与云计算平台负责人Amen Hamdan在今年CES主题演讲中透露，目前已经能提供一个嵌入式容器化应用的runtime，让开发者可以使用容器将应用打包后送到车上的实例做更新，而且可以将应用拆分，对个别小型功能进行更新。尽管他没有透露哪些汽车功能会先采用容器，但也预告：“今年把这项技术导入车上后，会推向更多车款。”他表示。
不只有车厂要让汽车支持容器技术，去年5月，红帽宣布要把企业级Linux带来汽车上，也成了未来容器可以跑在汽车上的另一个关键证据。
容器技术很早就在Linux平台上实现，对于Linux支持也更完整，例如最早推广容器而闻名的Docker就是基于Linux containers发展而来，但在众多支持Linux containers的IT厂商中，红帽发展脚步最快，从2014年RHEL 7操作系统就内置Docker，后来历经多个版本更新，对于容器应用功能支持更全面，发展到现在已经相当成熟。
从红帽宣布与通用汽车的合作中透露出，未来红帽车载OS将可以取得车上应用的底层控制权限，来支持安全和非安全车载相关应用，包括车载资讯娱乐系统、ADAS、车辆控制与车联网等。甚至很快地，全球第一辆搭载车用RHEL的汽车今年上半年就会亮相。意味着，原先红帽所拥有完整的容器开发平台、应用工具等生态系都准备就绪，未来可以运用到汽车中。
过去容器技术的出现，颠覆IT产业，掀起传统IT架构变革，如今，这项技术也开始进到传统封闭汽车产业，不只有机会推翻传统汽车应用部署和管理模式，更将引领汽车软件化发展往下一阶段迈进。
为何汽车软件需要容器化？
容器技术最大特色是为应用程序提供了一种标准封装格式，可以把应用程序连同环境一起打包，再发布到任何可执行容器的平台上，来方便管理、移动和部署应用程序。
使用这种封装格式，因为具有更好的移动性，软件开发人员可以很容易将容器化汽车软件部署到车上，不像采用传统封装的汽车软件，除了安装软件之外，通常需额外加装其他附加组件，来补足原本软件执行所缺少的相关组件，才能顺利执行。容器化汽车软件因为在封装过程中，已经预先把汽车应用软件程序、组态及其依赖性等所有执行需要使用的文件、程序库都打包起来，因此就不需要担心环境不一致的问题。这是容器化汽车软件和传统汽车软件最大的差异。
尤其，以后车厂需要常常为所有出厂的汽车更新软件，来提供各种汽车功能与体验服务，使用容器技术，就可以更容易通过OTA更新替换汽车组件上软件，来减少现场更新维护的人力，不需要采用跟过去一样更新方式，得由车主亲自开回原厂，再由车厂技师将更新文件安装到要更新的汽车设备上（如车载计算机等），就能完成汽车软件更新的动作，甚至遇到有一些公用性功能需要更新时，还能共享同一个更新文件，不需要根据入门、旗舰型等不同等级车款来调整，个别发布更新。
容器化技术也是最能体现“搭建一次，随处可用”精神。因此，用容器技术开发出来的应用，就可以很容易放在任何地方来执行，特别是在需要经常变动的汽车环境中，因为不需要考虑依赖性的关注和异动，所以它的流通性更高，可以快速扩展，将有助于汽车软件化生态的发展。
不过，汽车越来越软件化，也容易导致汽车内部软件系统越来越复杂且庞大，但通过容器技术，搭配其他调度管理工具，也能加以改善。
从软件开发流程来看，更能确保不论是在测试环境，或上线前准备环境进行测试，都能和正式环境那套软件环境保持一致，不容易受到不同环境配置差异的影响。
因为有了容器技术，也让软硬件解耦变得更容易。过去汽车软件开发流程上，必须考虑到车辆系统发布周期，导致软件开发周期变长，因为软硬件绑定，在软件化汽车趋势潮流下，首先就是要把硬件和软件架构分离，让软件可以单独开发， 来缩短开发周期。由于容器技术是以应用程序为中心的虚拟化技术，可以让这件事更容易被实现。
从硬件架构来看，过去汽车内部是一个大型分布式架构系统，配备许多ECU，各自提供不同车用功能，新一代汽车E/E（电子电气）底层架构逐渐走向集中式架构，在这个新架构下，原本分布在汽车中的ECU开始向上集中到少数主要ECU或汽车中央计算机的HPC平台上处理，也将带动汽车正式环境部署容器应用的需求，更进一步将汽车传统应用程序从ECU中移植到新架构，从而加速软件化汽车的发展。
与传统VM相比，容器化软件也更轻量，可以用最小的方式将软件所需执行的资源都封装在一起，成为一个容器映像，再部署到汽车新旧设备中。因为不需要借助操作系统来帮忙，因此就不需要先装好一个操作系统，所以较不占用空间，启动速度也更快。
容器本身拥有完整且成熟的生态系，是汽车拥抱容器技术带来的另一个好处，有许多现成容器开发和管理工具，以及安全工具等，都可以直接套用，甚至，容器技术也是目前主流，所以当车厂开始使用这个技术以后，原本专精于容器的这群人能直接进来，成为车厂开发容器化汽车应用即战力。
不过，初期，汽车容器化软件还是会以非安全相关的汽车应用为主，毕竟汽车软件仍与一般消费性或企业软件有所差别，更加强调功能安全性，不像手机软件宕机，只要重开就好，汽车软件一旦宕机，严重可能攸关生命安全，所以设计上必须把这些安全要求纳入考量。这也是为什么红帽开发汽车Linux花了2年多，就是要为了取得ISO 26262汽车功能安全的认证，才能够放进车上使用，这也成了容器技术进到汽车上后能不能有更多应用的挑战。
汽车产业第二次软件化变革
这不是汽车产业第一次技术大变革，而是近十年来第二次革新。过去因为电动汽车、自动驾驶汽车的出现，汽车设计开始从硬件转向软件为中心，掀起第一波汽车软件化的变革，从单一接口的软件化开始，到汽车基础架构软件全面性改变。也因为汽车软件越来越重要，甚至成了影响汽车应用或服务能不能更进一步延伸的关键。
从软件化更进一步发展到容器化应用，将是汽车软件化后下一阶段发展。不同第一次软件化变革，更追求软件敏捷和弹性，来满足未来更多汽车功能增长与频繁更新需求，更要改善因为这波软件化汽车风潮而越来越复杂的软件系统架构，方便在汽车中管理及部署。这是汽车产业迎来第二次的软件化变革。
不只是容器，未来更多云原生物科技术将走进汽车
传统汽车体质也因为这波新变革而有不一样的改变，让车厂更容易在汽车内采用云原生，来支持对于汽车应用程序进行快速更新迭代、转移或部署，不只增强敏捷性，还能提高员工生产力和缩短应用交付的时间。这些云原生物科技术，将成为加速推动汽车软件化发展另一个重要关键。
其实近两年，不少大型车厂早就导入云原生物科技术，运用容器、Kubernetes容器调度管理工具与微服务对汽车软件开发流程进行现代化工程改造，并结合DevOps与CI/CD测试部署自动化，借此来缩短软件开发周期，以便更快推出新功能，包括大众、奔驰、福特、通用等，都已经实际采用。
不过，现阶段想要在汽车上使用Kubernetes来管理汽车容器化应用，还是有困难，但为了管理这些汽车容器化应用，就需要有一个能管理汽车中多支容器的管理工具，为此，也有IT厂商试图寻找替代方案。例如，红帽就打算以Podman来取代Kubernetes，用来管理汽车内部多容器应用程序。
Podman同样也是容器管理工具，但与采用多节点集群架构的Kubernetes相比，Podman更加轻量，不需要处理多台Pod主机集群的网络连接、复杂的节点关系，因此就很适合在资源有限的汽车嵌入式环境中使用。
原本Kubernetes使用YAML档来描述工作负载，包括containers和pods，来减少管理的复杂度，因为Podman同样支持Kubernetes YAML档，当以Podman搭配systemd使用时可以支持Kubernetes应用描述，这意味着，可以在车辆中使用与云计算相同的Kubernetes声明或描述，使用YAML来管理在单个节点上的多个汽车容器应用，而没有Kubernetes本身多节点集群管理负担和复杂性。
从容器调度工具开始有了汽车专用版本的发展来看，也透露出，以后汽车环境不会只有单一容器，而是一个多容器的应用环境。甚至更进一步，还能发展成微服务架构。
嵌入式处理器设计大厂Arm也看好云原生将成为软件化汽车更进一步发展所必备的关键技术。从Arm所披露一张汽车软件化发展架构图也反应出这个趋势。未来汽车内部软件堆栈架构，将从传统服务导向SOA架构，逐步转向微服务架构的过程，在这个新架构下，以后汽车内部软件应用程序将全部变成一支支微服务程序，来取代传统单体式设计的应用程序。甚至更进一步，未来微服务架构还要能够支持混合关键性任务（mixed critically）调度需求，以便符合车规即时处理和功能性安全的要求。
对于汽车软件化发展而言，拆分微服务颗粒度的好处是，可以将单一应用程序分拆成多个小型功能的微服务，因此更能应对经常变动的汽车应用程序的环境所需。并通过API让不同微服务能够彼此沟通和相互串联来提供汽车服务。大众目前也正在尝试把这项技术运用在汽车上，未来还要通过API，让开发者可以很容易取得汽车功能相关数据进行应用开发。
当车厂开始把更多云原生带来汽车，以云原生物科技术打造汽车基础架构，就像现在许多大型企业数据中心都是云原生数据中心，大力拥抱基础架构程序代码化（Infrastructure as Code），使用软件的方法管理数据中心的设计、硬件架构和运维。汽车也就像是一个装轮子的云原生数据中心，让汽车基础架构应用开发、部署与运维，都可以通过自动化方式来执行时，汽车将不只是容器化汽车，更是一辆云原生汽车。
图片来源／Arm
从嵌入式处理器设计大厂Arm所披露一张汽车软件化发展架构图能看见，未来汽车内部软件堆栈架构，将从传统服务导向SOA架构，逐步转向微服务架构的过程。在这个新架构下，以后汽车内部软件应用程序将变成一支支微服务程序，来取代传统单体式设计的应用程序。甚至更进一步，未来微服务架构还要能够支持混合关键性任务（mixed critically）调度需求，以便符合车规即时处理和功能性安全的要求。
大型开源社群力推SDV风潮，也加快汽车软件容器化推动
过去2年来，软件定义汽车（Software Defined Vehicle,SDV）或软件化汽车风潮迅速崛起，不只是传统大型车厂积极投入，如大众、通用、福特、奔驰等，更有不少IT厂商、大型公有云企业抢进，就连大型开源社群都大力支持。
去年3月，旗下有许多知名物联网项目的Eclipse开源软件基金会，成立了一个新的SDV工作小组，这也是第一个由大型开源软件社群所成立的SDV项目计划。该小组任务是要为软件定义汽车打造一个程序优先的开源平台，目的是要彻底改变汽车产业传统软件开发方式，因此初期工作项目，包括创建车载应用runtime堆栈、云计算汽车OS与集成开发工具链，让汽车制造商和供应商可以安全可靠的方式部署、配置和监控车辆软件，也提供跨不同车型、车厂车载软件开发所用。初期成员有微软、ZF、Arm、Bosch、红帽、ETAS等，一年后成员数增加到30多家，日本汽车大厂丰田也加入。
其实，早在Eclipse SDV成立前，就已经有相关SDV开源项目推出，其中又以红帽主导的CentOS Automotive SIG为代表，不只要创建与汽车相关开源软件，更要改造CentOS发展汽车Linux，作为车厂打造新车载OS的参考设计与概念验证。
CentOS Automotive SIG成立不到一个月，另一家嵌入式处理器设计大厂Arm也力推SOAFEE新架构，这是一个可扩展嵌入式边缘软件框架，Arm希望借由SOAFEE架构，将云原生物科技术导入车用领域，加速推动SDV发展，包括自动驾驶、先进驾驶辅助系统（ADAS）等，让汽车企业更容易开发能在Arm设备执行的混合关键型应用。目前已有第一个版本发布。截至去年底参与该项目成员超过50家，涵盖半导体芯片厂商、软件供应商、系统集成商、云计算服务供应商、车厂与Tier1汽车供应商等。
就连知名代工大厂鸿海，也瞄准软件化汽车的商机，在2年前成立MIH开放电动汽车联盟，在鸿海号召下，成立一年就有超过2千家企业加入，希望借由打造开放汽车硬件框架打破传统封闭的汽车开发环境，让不只传统车厂，其他行业都能加入，进而推动汽车产业的变革。期间还发布了电动汽车开发者工具平台EV Kit，能提供纯电动汽车整车设计软件接口及硬件规格。至今更以此架构推出三辆不同等级的电动汽车。
通过引进这些开源软件与社群的力量，未来将会有许多开源工具、软件组件提供，搭配开放式硬件架构，将有助于未来汽车软件容器化加速发展。