业内专家表示，在Autosar
汽车软件平台内对差异性选择的追求正在导致软件的不兼容性，而这很有可能会对该标准所追求的高层次目标产生负面影响。这听起来简直令人啼笑皆非，因为Autosar是由汽车OEM和其一线供应商建立的，目的就在于控制汽车软件的复杂性和多样性。
Autosar标准(目前的版本是2.1)背后的主导思想，是通过一个严格定义的中间层把由软件实现的功能从车辆的微控制器和电子控制单元(ECU)硬件中分隔开来。Autosar协会的目标不仅是将关键的系统功能标准化，而且还要创制一个平台来整合由不同供应商提供的软件，从而提升整个行业的效率。
但就在标注即将实施之际，开发者面前却出现了障碍。一个主要问题是应该执行该标准的哪个版本。在标准的创建过程中，众多参与者(OEM及一线供应商)曾积极游说在该标准中加入并非所有协会成员都感兴趣的功能。例如，就开发人员必须在设计的哪个阶段采用特定通信战略这个问题，该标准就提供三种可能性。定义通信拓扑和ECU协议的策略既可在前编译(precompile)阶段，也可在链接阶段决定——前者可使运行不同软件的ECU以固定方式通信；后者则允许某种灵活性。
在瑞典汽车制造商沃尔沃(Volvo)的积极游说下，该标准组织包括了一个附加的“postbuild”通信行为选项，为设计师带来了最大程度的灵活性。但是，沃尔沃似乎是使用该功能特性的唯一OEM。“诸如此类的事情使标准的定义更庞杂，从而牺牲了简明性。”一位不愿透露姓名的行业专家表示，“结果是，许多供应商提供了不同的标准定义子集。”
在近期于德国斯图加特召开的Euroforum汽车软件大会上，汽车零部件供应商罗伯特·博世(Robert Bosch GmbH)有限公司针对与Autosar兼容的构建模块，提交了其“购物车(shopping cart)”概念。但是在Bosch公司的陈述结束后，与会者却表示对该方法半信半疑。
针对与会者提出的有关具体实施时的开放性和完整性问题，Bosch汽车系统整合业务总经理Walter Grote表示：“我们的开放程度与任一家超市一样，但也可能出现并非所有希望功能都准备就绪的情况，或者在试图整合不同供应商的模块时，需要费些周折考虑如何进行匹配。
这里所说的“周折”的潜台词是指，软件即插即用兼容性这一崇高目标可能永远是句空话，即使对Autosar来说也是如此。Grote指出，开发者将不得不进行权衡处理，即“执行的越完整，对ECU资源的需求就越高”，特别是对存储容量以及计算能力的需求。
“那些只涵盖了子集的经‘剪裁’的系统，实现起来资源效率要高得多，”一位业内人士对上述说法表示认同，“考虑到汽车硬件巨大的价格压力，许多供应商确实会选择向客户提供其软件的简化版本，但是根据客户和应用领域的不同，这些简化版本之间有很大的差别。”
Bosch的Grote间接同意了上述看法。“目前，除非能为ECU配备极为丰富的资源，否则Autosar软件尚不具备即插即用功能，”Grote说，“但是，对这个规模以数百万台计算的市场来说，这是不被容忍的。”
Autosar软件的实时行为也造成了“不合谐音”。虽然Autosar为开发实时软件提供了一套方法论，但是业界仍然必须处理一大堆参数。“这是一个无法固定的目标。”宝马子公司Car IT的CEO Harald Heinecke在斯图加特的大会上表示。
实时性问题
“这是存在于一线供应商和OEM之间的问题，”一位与会者在宝马公司陈述后的讨论中表示，“在多数情况下，OEM并不掌握诸如延时和抖动等相关实时信息。”Heinecke对此表示赞同，认为这个难题需要由OEM解决。
一个问题是，Autosar在挑战传统的汽车业务模式，在该模式下，OEM定义并开发软件模块，而一线供应商则提供硬件并进行整合。Autosar试图开创一个PC类模式，由独立第三方提供软件。
尽管存在上述所有顾虑，但是咨询公司Extessy AG的CTO Hans Martin Schulz对此却仍持乐观态度：“眼下，我们看到业界正在打造各种涵盖Autosar特定功能的工具。完整的Autosar流程现在还没有确定。我们预期，向Autosar标准的转换要历经几年时间，”他说。
定于今年秋季发布的Autosar 3.0版本，预计将解决2.1版本中的若干问题。“这里指的是ECU的启动/唤醒，以及Autosar设计方法学。”Autosar发言人Hartmut Fennel表示，“另外， 3.0版本将包括更多与车身、动力传动和底盘控制相关的功能接口和部件定义。”
4.0版本预计将于2009年秋季发布，其中将增加兼容性测试、安全性能及更多功能接口。