几个著名的软件开发灾难性事故

合集下载

软件危机的案例

软件危机的案例

软件危机的案例
软件危机的案例有:
1.IBMOS/360:这是一个经历了数十年,极度复杂的软件项目,被认为是软件危机的一个典型案例。

这个项目使用了1000人左右的程序员,最终产生了一套不包括在原始设计方案之中的工作系统。

在项目管理过程中,曾经出现了价值数百万美元的错误。

2.美国银行信托软件系统开发案:美国银行在1982年进入信托商业领域,并规划发展信托软件系统。

项目原订预算2千万美元,开发时程9个月,预计于1984年12月31日以前完成,然而至1987年3月都未能完成该系统,期间已投入6千万美元。

美国银行最终因为此系统不稳定而不得不放弃,并转移了340亿美元的信托账户,损失了6亿美元的信托生意商机。

除了上述案例外,还有如火箭发射失败、银行账户错误记账、导弹防御系统失败等软件危机案例。

这些案例表明,软件危机可能导致项目超出预算和进度计划,甚至可能导致严重的后果,包括人员伤亡和财产损失。

对软件的开发和维护需要采取更加严谨和系统的管理方法,以避免类似的危机发生。

软件危机实例案例分析

软件危机实例案例分析

软件危机实例案例分析引言:在当今数字化时代,软件在各个领域的应用越来越广泛,不仅给人们的生活带来了便利,也在各个行业中发挥着重要的作用。

然而,与软件的广泛应用相比,软件危机问题也时有发生。

本文将通过分析几个软件危机实例案例,探讨软件危机的原因、影响以及解决方法。

案例一:1999年美国导弹误射事件1999年,一枚巡航导弹在南塔斯山的中国使馆上空误射,导致了几名中国使馆人员的死亡和重大的外交纠纷。

事后的调查发现,这是由于导弹的软件错误和人为操作失误导致的。

导弹的软件系统没有正确地识别中国使馆的坐标,同时,操作员也没有进行必要的确认和核实。

这一事件揭示了软件设计和操作失误对于重大事故的潜在影响。

案例二:2003年英国医院病人数据丢失事件2003年,英国国民保健服务(NHS)发生了一次重大的数据丢失事件。

由于软件系统更新不当,140万病人的数据在系统中丢失,导致了长时间的混乱和不便。

患者的病历、检查结果等重要信息丢失,医院的正常运作受到了很大的影响。

这一事件揭示了软件系统更新和数据管理的重要性,以及错误操作对于数据安全的潜在威胁。

案例三:2010年美国联邦航空管理局(FAA)软件故障2010年,美国联邦航空管理局(FAA)的航空交通控制系统发生了故障,导致了全国范围内航班延误和取消。

这是由于软件系统中一个小错误引发的,导致整个系统瘫痪。

上万名旅客受到了影响,航空公司遭受了巨大的经济损失。

这一事件揭示了软件系统中小错误的潜在影响范围,以及软件系统对于航空交通安全的重要性。

案例四:2017年Uber数据泄露事件2017年,全球最大的打车软件公司Uber曝出了一起数据泄露事件。

黑客入侵了Uber的系统,获取了5700万用户和600万司机的个人信息,包括姓名、电话号码、电子邮件地址等。

这次数据泄露事件严重违反了用户隐私安全,给用户带来了极大的不安和风险。

Uber在事件曝光后付出了巨大的代价,不仅面临法律诉讼,还失去了大量用户的信任。

关于软件缺陷的小故事

关于软件缺陷的小故事

关于软件缺陷的小故事
1、美国迪士尼公司的狮子王游戏软件
1994年迪士尼公司推出的狮子王游戏,但是由于急于推出,没有在对市面上的PC机进行兼容性测试,导致很多PC机器安装游戏之后崩溃,导致后续用户进行大量的投诉。

2、火星登录事故
这个不知道了解的信息是否是正确的,火星登陆的时候,由于数据计算错误导致在火星登录器还未着陆时,判断到已经着落,从而提前释放了降落伞和保护罩,导致火星登陆器坠毁。

3、跨世纪千年虫问题
2000年之前由于时间表示是用YYMMDD这种方式,用二位10进制数据表示的,但是到2000年时,两位数的表示就会出现争议,争议到底是1900年还是2000年,甚至还有闰年的判断上也会出现争议,特别是一些需要跨时间计算的数据,这样会导致系统等一系列崩溃。

后续就采用了YYYYMMDD的表示方法。

这个是千年虫是由于程序BUG引起的问题,并不是病毒。

三次软件危机的表现及起因

三次软件危机的表现及起因

软件危机:落后的软件生产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题的现象。

第一次软件危机(60年代~70年代)20 世纪60年代以前,计算机刚刚投入实际使用,这个时期主要的软件开发方式是使用机器语言或者汇编语言在特定的机器上进行软件的设计与编写。

此时的软件规模较小,文档资料通常也不存在,也不需要使用系统化的软件开发方法,基本上是个人设计编码、个人操作使用的的私人化的软件生产模式。

这个时代的程序一个典型特征就是依赖特定的机器,程序员必须根据所使用的计算机的硬件特性编写特定的程序。

然而从60年代中期开始,大容量、高速度计算机问世,使计算机的应用范围迅速扩大,软件开发急剧增长。

高级语言开始出现;操作系统的发展引起了计算机应用方式的变化;大量数据处理导致第一代数据库管理系统的诞生。

软件系统的规模越来越大,复杂程度越来越高,软件可靠性问题也越来越突出,程序设计的复杂度也随之增长。

原来的个人设计、个人使用的方式不再能满足要求,迫切需要改变软件生产方式,提高软件生产率,软件危机开始爆发。

1968 年北大西洋公约组织的计算机科学家在联邦德国召开国际会议,第一次讨论软件危机问题,并正式提出“软件工程”一词,从此一门新兴的工程学科——软件工程学——为研究和克服软件危机应运而生,“软件危机”的概念也是在那次会议上由F. L. Bauer提出的。

当时业界最迫切的需求是需要在不损失性能的前提下获得更好的“抽象性”和“可移植性”。

此时,比汇编和机器语言更高级的语言相聚诞生,典型的代表莫过于C语言(1972年)。

C语言让程序员能让程序员编写的代码在没有或只有较少机器相关性的同时又有不输于汇编语言的性能,而且丰富的语言特性也使得编程难度大大降低,成功的解决了“抽象性”和“可移植性”的问题。

早期出现的软件危机主要表现在:① 软件开发费用和进度失控。

费用超支、进度拖延的情况屡屡发生。

有时为了赶进度或压成本不得不采取一些权宜之计,这样又往往严重损害了软件产品的质量。

世界上著名的软件危机事件及你的思考

世界上著名的软件危机事件及你的思考

世界上著名的软件危机事件及你的思考文章标题:探讨世界上著名的软件危机事件及个人思考一、引言软件危机,作为软件工程领域的一个重要课题,涉及到软件开发过程中可能出现的种种问题和挑战。

在软件开发的历史长河中,有不少著名的软件危机事件,它们给人们留下了深刻的教训和思考。

在本文中,我们将对世界上著名的软件危机事件进行全面评估,深入探讨其原因和影响,并结合个人观点和理解进行思考和总结。

二、著名的软件危机事件1. NASA的阿里安5号飞船发射失败事件阿里安5号飞船是法国航天局研制的一款运载火箭,1996年6月4日,阿里安5号飞船在升空12秒后突然发生错误,最终导致飞船在太空中爆炸。

这一事件令人震惊,也引发了对软件问题的深刻反思。

据调查显示,飞船爆炸的原因之一是软件错误导致了飞船的飞行姿势错误,最终导致了飞行失败。

这一事件成为了软件危机的典型案例之一,也促使了软件工程领域对于软件开发质量和安全性的更加重视。

2. 美国联邦航空管理局的自动化系统升级项目在上世纪80年代末至90年代初,美国联邦航空管理局进行了一项大规模的自动化系统升级项目,旨在提高空中交通控制系统的效率和精度。

然而,由于项目中的软件问题和技术挑战,该升级项目出现了严重的延误和预算超支的问题,最终导致了该项目的失败。

这一事件引起了软件工程领域对于大规模软件项目管理和技术实现的思考,也为未来的软件开发提供了重要的经验教训。

三、对软件危机事件的思考软件危机事件是软件工程领域中的重要课题,也是我们需要深入思考和反思的问题。

对于这些事件,我们需要从多个角度进行分析和思考。

我们需要思考软件危机事件背后的深层原因,包括软件开发流程、工程管理、技术实现等方面的问题。

我们需要从技术、经济、政治和社会等多个维度去理解软件危机事件的影响和意义。

我们需要结合个人经验和观点,对软件危机事件进行深刻的总结和反思,从而为未来的软件开发提供更多有益的启示和建议。

我个人认为,软件危机事件的发生并非偶然,而是背后存在着多方面的原因和机制。

软件危机实例案例分析

软件危机实例案例分析

软件危机实例案例分析引言随着科技的快速发展和智能化的进步,软件已经渗透进入我们生活的各个方面。

从智能手机上的应用程序到银行系统的核心软件,软件已经成为了现代社会不可或缺的一部分。

然而,在软件的发展过程中,也经常会出现各种危机和问题。

本文将通过分析一些实际的软件危机案例,来深入探讨软件危机的原因和解决方案。

一、2003年美国东部大停电事件2003年8月,美国东北部地区遭遇了一场历史上最严重的停电事件。

停电导致数百万人口陷入黑暗中,交通系统瘫痪,经济活动中断。

初步调查显示,停电的直接原因是一台重要的线路故障。

但更深层次的原因则是市场危机和软件系统的故障。

市场危机方面,电力公司由于盲目追求利润,将维护和升级电网的投资降到了最低,导致电网老化和负荷过重。

软件系统方面,则是由于电网的复杂性和规模庞大,传统的手动维护方式已经无法满足需求。

为提高效率,电力公司采用了自动化的软件系统,但该系统存在软件缺陷和漏洞。

针对这一危机,电力公司立即启动了紧急措施来修复电网,并调查了软件系统的缺陷。

结果发现,软件系统设计上存在严重的漏洞和错误,无法正确识别并处理电网的异常情况,导致故障扩大化。

此事件再次凸显了软件系统的重要性和安全问题。

二、2014年心脏植入物异常事件2014年,全球范围内发生了一系列与心脏植入物相关的异常事件。

这些异常事件主要涉及到植入物的软件系统缺陷和安全问题。

例如,一些心脏起搏器和除颤器被黑客攻击,导致患者心脏停止跳动或者电击过度。

这些异常事件使得人们意识到植入物软件系统的重要性和安全问题。

以往,开发植入物软件系统主要考虑功耗和可靠性,安全性则没有得到足够重视。

针对这一问题,医学界和软件行业展开了深入合作,共同提出了软件安全标准和测试方法。

此外,加强对植入物软件系统的监管和审查也成为了必不可少的措施。

三、2017年世界各地恶意软件攻击2017年,全球范围内爆发了多起规模庞大的恶意软件攻击事件,例如“永恒之蓝”和“想象力”等病毒。

软件开发事故分级对照表

软件开发事故分级对照表

软件开发事故分级对照表
软件开发事故的分级标准可能因组织、行业或地区而异,但通常会根据事故的影响范围、严重程度和处理难度进行分类。

下面是一个简化的软件开发事故分级对照表:
事故等级影响范围严重程度处理难度
:--: :--: :--: :--:
1级较小范围轻微影响低
2级局部范围一定影响中等
3级较大范围较大影响高
4级全局范围严重影响极高
这个表格提供了一个大致的分级标准,具体的事故等级还需要根据实际情况进行评估。

在评估软件开发事故时,可以考虑以下几个方面:
1. 影响范围:事故影响的用户数量、系统范围和业务领域。

2. 严重程度:事故对用户、业务和公司声誉的影响,以及恢复所需的时间和资源。

3. 处理难度:修复事故的复杂性和技术难度,以及需要投入的资源和人力。

根据这些因素,可以将软件开发事故分为不同的等级,并采取相应的处理措施。

对于较轻的事故,可能只需要进行快速修复和恢复;对于较严重的事故,可能需要启动应急响应计划,协调多个团队和资源进行修复和恢复。

软件危机的例子

软件危机的例子

软件危机的例子近年来,随着科技发展的进步,软件系统也变得越来越复杂,而软件危机也随之而来。

这些软件危机会对用户造成负面影响,也会给企业带来极大的损失。

本文将分析一些软件危机的例子,以了解危机的严重性和可能造成的影响。

首先,值得注意的是,一个系统的软件漏洞可能造成的影响是相当严重的。

以苹果的操作系统越狱漏洞为例,该漏洞可让攻击者不需要登录凭证就能破解用户的iPhone或iPad,从而获得用户的数据和隐私信息。

这个漏洞不仅给苹果造成了极大的影响,而且也让用户面临着信息被窃和隐私泄露的风险。

其次,软件缺陷可能造成的影响也是非常严重的。

以英特尔处理器的超线程缺陷为例,它可能会让攻击者获得更多的系统访问权限,窃取用户的数据,即使是机密数据也不例外。

英特尔面临着被客户索赔的风险,且难以挽回声誉损失。

最后,软件的任意代码执行漏洞也是一种潜在的危机。

以华为的路由器漏洞为例,攻击者可以利用该漏洞远程控制华为路由器,篡改用户的网络设置,从而可能导致用户的上网行为受到报复性攻击,且也会让企业面临着客户流失和声誉损失的风险。

以上三个例子说明了软件危机的严重性,攻击者利用软件漏洞、缺陷或任意代码执行漏洞,可以获得更多的系统权限,窃取用户的数据,乃至于控制系统的某些功能,从而对用户或企业造成巨大的损失。

为了预防和应对软件危机,企业应该持续加强软件安全意识,并采取一系列措施来改善软件安全性。

首先,在软件开发和部署过程中应该采用一些合规的规范和标准,如系统风险分析、系统架构设计、系统工程测试等,以确保软件系统的安全性。

其次,企业应经常对软件进行安全审计,及时发现存在的漏洞和缺陷,并立即采取相应的措施,以保证软件系统的安全运行。

最后,企业应该积极与安全软件厂商合作,实施安全升级和补丁管理,以确保软件的最新版本是安全的。

综上所述,软件危机的发生会对用户和企业造成巨大的损失,因此,企业应加强软件安全意识,采取合规的规范和标准,定期进行安全审计,以及积极与安全软件厂商合作,确保软件系统的安全性和可靠性。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件事故我们都知道软件中的Bug非常令人讨厌。

但同时有缺陷的软件还有可能造成重大甚至致命的事故。

下面是一些非常有名的软件事故:一、1962年,水手号火箭的致命BUG。

经济损失:1850万美元1962年,携带空间探测器的水手1号火箭前往金星,在起飞后不久就偏离了预定航线。

任务控制在起飞293秒后摧毁了火箭。

事故的起因就在于一名程序员把一条手写的公式抄写为错误的计算机代码。

从而将火箭引导偏离了航向。

二、1978年, 哈特福德体育场倒塌事件.经济损失: 7000万美元1978年, 在上万球迷离开哈特福德体育场几小时后, 体育场屋顶就被雪压塌了. 起因在于分析受力的程序错误地假设钢结构屋顶的支撑仅承受纯压力. 但当其中一个支撑因大学塌了后,导致连锁反应, 从而导致整个体育场的塌陷.三、几乎引发的第三次世界大战.1983年, 苏联导弹预警系统错误地报告遭到美国发射的5枚导弹攻击. 但幸运的是,当时的负责人认为如果美国真的要攻击的话, 发射的决不只是5枚导弹. 最终没有酿成大灾难.四、软件故障可能导致“爱国者”导弹发生事故 2003年3月30日11:13 舰船知识网络版[美国《华盛顿邮报》2003年3月26日报道]数天内美国"爱国者"接连出现问题,已经引起人们对该系统瞄准软件存在问题的关注。

美官员称,3月24日在伊拉克纳杰夫城南50千米的"爱国者"系统显然"锁定"了空军的F-16战机,并准备开火,F-16马上对导弹连发射了HARM高速反辐射导弹,摧毁了其雷达碟型天线。

这次攻击没有人员伤亡,这次F-16的反应挽救了飞行员的生命,但前一天在伊科边境,"爱国者"导弹曾击落了英国皇家空军旋风GR4战机,当时有两名飞行员毙命,这成为此次战争首位被友军误伤的人员。

华盛顿对此也非常谨慎。

沙特苏丹王子空军基地国防部和空军指挥中心的官员认为这两次事件有明显不同,沙特空军官员也认为,目前尚无法肯定"爱国者"锁定了F-16或飞机正在探测伊拉克防空雷达。

但有很多专家并不这样认为。

一位防务官员说:"这明显是软件错误,虽然喷气机非常快,但肯定要比飞毛腿导弹慢"。

有专家指出,两次事故的细节使人们对人为错误的解释产生怀疑。

沙特的防务官员说,在星期一的事故中,"爱国者"连在向北机动保护第3机步师向巴格达开进时,遭遇迫击炮火射击,"爱国者"导弹操作员进行了隐蔽,此时导弹连在很大程度上处于自动状态,而隐蔽行动也挽救了美军人员,但其表明"爱国者"导弹系统瞄准了F-16,而非人为错误。

国防部长拉姆斯菲尔德在星期天说早些时候英国飞机的失事要么是由瞄准识别设备的问题或因为英国飞机没有启动敌我识别信号。

但专家指出,"旋风"在返回科威特时曾被多个防空系统跟踪,而只有一个"爱国者"连开火。

这显然存在问题。

2002年2月,由于电路短暂地过载使雷达失去信号,导致"爱国者"试验失败,该故障可能对瞄准造成干扰,而此类问题有可能再次发生。

1991年海湾战争期间,"爱国者"在对飞毛腿导弹的拦截中几乎没有发挥作用,从那时起,该系统进行了3次改进。

而此次开战伊始,伊拉克就向科威特的美国军队发射了导弹,国防部称已经拦截了6枚。

即使"爱国者"系统存在问题,但目前尚无法将其撤出行动。

五、软件错误原因造成2003年美加最大停电事故著名安全机构SecurityFocus的数据表明,2003年8月14日发生的美国及加拿大部分地区史上最大停电事故是由软件错误所导致。

SecurityFocus的数据表明,位于美国俄亥俄州的第一能源(FirstEnergy)公司下属的电力监测与控制管理系统“XA/21”出现软件错误,是北美大停电的罪魁祸首。

根据第一能源公司发言人提供的数据,由于系统中重要的预警部分出现严重故障,负责预警服务的主服务器与备份服务器接连失控,使得错误没有得到及时通报和处理,最终多个重要设备出现故障导致大规模停电。

预警系统崩溃后没有接收到更多的警报更没法向外传播,操作员并不知道预警系统已经失效,他们发现了部分异常情况,但因为没有看到预警系统的警报,而不知道情况有多么严重,以致一个小时后才得到控制站的指示。

但此时没完没了的故障干扰已经让操作员反应不过来,无法控制整个局面。

正常情况下,出现错误的网络会立即与其他网络分隔开来,这样一来错误就会被固定在一个地方,但是同样由于预警系统失灵,操作员没有做出应有的反应,最终使得错误蔓延,一发而不可收拾。

六、暴风影音“召回”全部软件曾引发六省断网事故哗然!当暴风影音总裁冯鑫昨日在发布会上宣布召回1.2亿播放软件后,现场一片哗然。

业界可能不会想到“5·19”南方六省断网事故引发了中国首例软件召回案。

在5月19日黑客攻击DNS域名服务器造成连锁反应,最终酿成南方六省断网事件中,暴风播放软件的海量用户请求被认为是重要“诱因”之一。

尽管暴风影音一直强调自己也是受害者,但是不少网友对暴风软件程序内部留下过多的后门进程产生质疑。

而正是这些进程,导致在南方六省网络瘫痪的巨大域名解析请求中,来自暴风影音的流量达到40%之多。

昨日冯鑫终于站出来承认:“我认为,暴风用户的巨大请求量成为此次断网事件中的主要因素。

为了避免类似事件再发生,今天决定针对所有1.2亿用户召回所有的旧版本播放软件。

”暴风公告称,从昨日起,暴风网站已经停止之前所有版本软件的下载,并且将于6月19日推出全新版本的暴风影音。

据暴风技术人员透露,新版暴风影音将对程序进行三大改进:一是去除升级互联网程序的开机启动,预计该举措将降低请求数量到原来的60%;二是升级程序可视化运营,改为用户可自己选择,预计该举措将降低请求数量到原来的40%;第三是大幅优化网络异常请求数量,预计该举措将降低请求数量到原来的20%。

该人士表示:“通过以上3个举措,预计在正常情况下,将请求数量降低到原来的10%-15%。

”作为中国首个软件召回案,不少分析人士认为暴风此举不乏某种程度的炒作嫌疑。

因为暴风影音软件并不通过光盘形式销售,而是用户直接从网络下载到电脑上,不存在产品召回的问题。

不过冯鑫却表示,暴风做出召回行动是需要付出巨大的经济损失的。

暴风内部人士为记者算了一笔账:“召回不仅包括租用服务器、带宽等硬成本,另外,由于关闭下载,将导致每天损失80万-90万的新增用户,这个成本不是能用具体金钱来衡量的。

”该人士特别强调,“在大约30天的时间内暴风将停止新增广告的投放,这个损失绝不小于对于召回的硬成本”。

但是问题在于,当付出了这些经济代价之后,这起中国首宗软件召回案能够在多大程度上挽回企业声誉,这至少要等到6月19日才能见分晓。

暴风影音计划投资“断网门”另一主角DNS pod昨日,暴风影音在宣布召回1.2亿软件的同时,有内部人士向记者透露,暴风公司将会向“5·19”断网事件的另一主角DNSpod投资。

在“5·19”南方六省断网事件中,DNSpod为暴风影音提供免费的域名解析服务。

但不幸的是由于DNSpod服务器遭受黑客攻击瘫痪,导致暴风影音的海量用户服务请求无法解析,造成一系列连锁反应。

DNSpod负责人吴洪声对记者证实,确实暴风影音总裁冯鑫已经就此事和其联系过,不过仅仅涉及意向,没有任何实质性内容,但是未来如何还需看DNSpod发展的需求。

而来自暴风方面的人士则表示,暴风有强烈的愿望投资DNSpod,而且是以真金白银的方式进行合股式投资。

该人士强调:“即便投资成功,暴风也不会干涉任何DNSpod的日常运营。

”七、丰田承认汽车黑匣子阅读器存在软件缺陷[业界要闻] 据纽约时报报道,日本头号汽车制造商丰田汽车近日表示,已经对召回汽车存在的故障进行了修复,但同时承认,在汽车突然加速案例中,黑匣子阅读器或存在软件缺陷。

丰田汽车表示,用于对黑匣子进行读取的阅读器存在一个软件方面的故障,该故障可能导致数据记录模块出现记录错误,误导了事故发生时司机对于车速的判断。

这一结论与早前调查得出的大多数事故均系人为因素造成的结论仅一月之隔。

Automotive曾撰文报道称,丰田相关领导已经承认之前所发生的事故,但对于究竟是何地方导致了故障却并没有明确指出。

目前,对于丰田汽车的意外加速事故,软件制造商也正在着手对车辆进行调查。

丰田汽车表示,目前已经发现了软件故障的原因,并对其进行了修复。

丰田表示,能保证今后所记录的数据准确无误。

但软件问题并不会对油门踏板以及刹车应用产生影响。

对此,业界分析师认为,这些信息将为以后发现丰田突然加速的真正原因提供关键线索。

但丰田对阅读器软件问题的表态使得人们对黑匣子的可信度产生了怀疑。

黑匣子又被称为事故数据记录器(event data recorders,EDR)。

截至目前,丰田在全球累积召回的汽车数量已经超过了1100万辆,目前接到的诉讼达到数百起。

美国汽车安全研究中心(Centre for Auto Safety)的主管克拉伦斯迪特劳(Clarence Ditlow)表示:“我们目前无法再通过EDR去判断是否出现了突然加速事故。

我们不能再相信丰田的一面之词,即黑匣子可以准确无误的记录事故。

丰田之所以这样说是希望能将其责任推的一干二净。

”据了解,除了汽车速度,事故数据记录器记录的信息还包括油门位置和刹车压力。

8月,丰田汽车在对3000起关于突然加速问题的投诉进行调查后表示,调查结果显示,丰田汽车不存在导致汽车失控的电子故障。

丰田汽车研发执行副总裁Takeshi Uchiyamada近日表示:“丰田汽车事故数据记录器没有故障,只是由于受病毒感染所致,读取数据的软件读取的汽车速度并不准确。

”Takeshi Uchiyamada还表示:“我们在今年春季发现读取事故数据记录器的软件存在病毒,读取的速度有误。

之后,我们便将这一软件故障排除。

”在美国高速公路安全管理局对丰田汽车突然加速故障进行调查之际,丰田透露了速度读取不准的内情。

丰田汽车旗下美国部门的发言人麦克·米歇尔斯(Mike Michels)表示,此次软件故障并没有影响其他数据的读取,特别是那些在事故发生之前的数据。

对于未来,我们仍对这个阅读器充满了信心。

”。

相关文档
最新文档