Subject: RISKS DIGEST 10.15 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 26 July 1990 Volume 10 : Issue 15 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: [*** HELLO-AGAIN EXPERIMENT WITH A NEW SENDMAIL... ***] Benefits and Risks of Knowledge-Based Systems (Brian Randell) CB "Traffic Advisory Channel" petition (Mark Draughn via Peter Jones) New Bank Software => Problems (Jeff Johnson) Viper and its Formal Verification (Brian Randell) Cellphone risk to ABS? (Martyn Thomas) Car phones and electronic systems (Tim Duncan) Washington State Ferries slide into home (Joe Dellinger) Pentagon Pizza (Jim Harkins) Logica Code Slows Trident (Mark Smith) GAO slams FAA computer systems (Rodney Hoffman) BMW Drive-by-wire (Rodney Hoffman) British air defense computer suffers a "nervous breakdown" (Walt Thode) British Rail signalling software problem (Pete Mellor) Call for Papers on Testing, Analysis and Verification (Nancy Leveson) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]GET RISKS-i.j ; j is TWO digits. Vol summaries in risks-i.00 (j=0); "dir risks-*.*" gives directory listing of back issues. ALL CONTRIBUTIONS ARE CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. ---------------------------------------------------------------------- Date: Thu, 5 Jul 90 18:18:16 BST From: Brian Randell Subject: Benefits and Risks of Knowledge-Based Systems Readers of RISKs might be interested in a recent Oxford University Press paperback book "Benefits and Risks of Knowledge-Based Systems" (ISBN 0-19-584743-9). This is a 76-page Report of a Working Party of the (UK-based) Council for Science and Society, chaired by Professor Margaret Boden (Prof of Philosophy and Psychology at the School of Cognitive and Computing Sciences, University of Sussex). The main chapter headings are: 1 How Knowledge-Based Systems Work 2 Applications of KBSs 3 The Benefits and Dangers of KBSs 4 Influencing the Future Uses of KBSs 5 Conclusions and Recommendations Summarizing the final conclusions and recommendations: 1 The general level of public awareness about the applications and social implications of KBS is low, and education about KBS should be included in school courses. 2. There should be more interdisciplinary undergraduate and postgraduate study programs in cognitive sciences and KBSs. 3. A government initiative applying KBSs to health education and health care would be popular and in the long term cost-effective. 4. A KBS should complement human workers rather than replace them. 5. It is undesirable to substitute a computer for a human function, such as the giving of psychiatric help, that should involve respect, understanding, empathy or love between humans. 6. Great attention should be given to the immense hazards presented by possible malfunctioning of military command and control systems and autonomous decision-making programs. 7. The Data Protection Act should entitle people to know not only what data are held about them, but also the rules by which they are processed. 8. Statutary regulation of KBS standards may be needed in future. 9. KBS vendors should adopt a suitable Code of Practice. 10. Meanwhile they should be legally obliged to insure themselves against claims for damages by users. 11 Various industry standards are needed, especially in the interface between the program and the user. 12 Professional associations such as the Society for the Study of Artificial Intelligence and the Simulation of Behaviour, and the Expert Systems Group of the BCS should adopt a code of conduct for their members. 13 Setting up a formal body for KBS practitioners with restricted membership is *not* recommended. Brian Randell, Computing Laboratory, University of Newcastle upon Tyne, UK EMAIL = Brian.Randell@newcastle.ac.uk PHONE = +44 91 222 7923 FAX = +44 91 222 8232 ------------------------------ Date: Wed, 27 Jun 90 13:53:37 EDT From: MAINT%UQAM@ugw.utcs.utoronto.ca Originally-From: Mark Draughn Sender: Short Wave Listener's List Subject: Re: Call for Comment, CB "Traffic Advisory Channel" petition I am reposting this, after being told that my original postings were only seen on BITNET. Sorry BITNET readers for a possible quadruple posting :-( [It has also been posted on SWL-L.] ---------------------------Original message---------------------------- A posting appeared recently on the SWL-L list regarding a computerized information system that informs motorists about traffic conditions: >Here in Chicago, the Illinois Department of Transportation operates a >group of low-power AM stations that provide traffic information. > >The stations broadcast at the top and bottom of the dial (540 and 1610 >I think). The broadcast alternates between events affecting traffic >and actual traffic reports. It is all automated. > >There is a tape that describes the daily schedule for construction >work, lane closures, ramp closures, parades, and other events >affecting traffic. > >This alternates with computerized traffic reports: "As of ... 5:55 pm >... there is severe congestion on the following currently monitored >sections of the highway system ... Kennedy expressway ... inbound ... >between Montrose avenue ... and Irving Park road ... between Kedzie >avenue ... and the Ohio street junction ..." and so on. The reports >are updated every 10 minutes or so by sensors buried in the highways. > >[text omitted] > >One problem with this system is that when traffic comes to a complete >stop somewhere, the computer doesn't detect cars moving over the >sensors and decides that there is no traffic. This is fairly rare. >[text omitted] > >It's a system that I like a lot. I find it amusing that this user likes the system, despite its apparently well-known tendency to be completely wrong in worst-case conditions. I wonder if people from out of town are told about this quirk, or left to discover it on their own. >EMAIL: draughn@iitmax.iit.edu+--------------+ Academic Computing Center >BITNET: SYSMARK@IITVAX | Mark Draughn | 10 W. 31st St. >VOICE: +1 312 567 5962 +--------------+ Illinois Institute of Technology >ALSO: ...{nucsrl|att}!iitmax!draughn Chicago, Illinois 60616 ------------------------------ Date: Fri, 06 Jul 90 11:12:36 PDT From: Jeff Johnson Subject: New Bank Software => Problems Today I called my bank (Bank of the West) to transfer some money from one account to another. Before initiating the transfer, I asked for the balance in the source account. The amount the teller said was in my account seemed somewhat high, but in the right ballpark. Since I hadn't balanced my checkbook recently and since it covered the amount I was about to transfer out, I initiated the transfer, thanked the teller, and hung up. Immediately after getting off the phone, I balanced my checkbook, and realized that the amount she had read to me was about $2K too high (though the correct amount still covered the transfer). I called back immediately, this time getting a different bank worker. I told her that the amount I had been given earlier was incorrect. She said that the bank had just installed "new software" the previous day, and all account balances were temporarily wrong until "things sort themselves out", which would be a day or so. She said that, unfortunately, not all the bank's employees were aware of the problem. I wonder what "until things sort themselves out" means. "Until all transactions recorded in the old system are entered into the new one", perhaps? If so, why didn't they do this before putting the new system on-line to workers? Maybe "until bugs in the software are fixed?" If so, their testing of the new software was seriously inadequate. JJ ------------------------------ From: Brian Randell Subject: Viper and its Formal Verification Date: Mon, 9 Jul 90 9:37:15 BST The RSRE Viper microprocessor and Avra Cohn's report on its formal verification, have been discussed earlier in RISKs. Readers may therefore be interested in the following article, by Simon Hill, which appeared on p.3 of the (UK) Computer Weekly for July 5, 1990. It is reprinted here in its entirety, without permission. Brian Randell, Computing Laboratory, University of Newcastle upon Tyne, UK :: USER THREATENS COURT ACTION OVER MoD CHIP :: :: The first commercial user of the Viper safety-critical chip developed :: by the Ministry of Defence is threatening legal action for alleged :: misrepresentation. :: :: Teknis International Railroad Systems of Adelaide, Australia, is :: seeking assurances that the Viper technology can meet the claims that :: the MoD and its commercial partners make for it. :: :: Teknis, which is developing a signal and railway crossing control :: system using Viper for the Australian National Railway Commission, is :: also threatening action against the MoD's commercial licensee, Charter :: Technologies. :: :: Worcester-based Charter was licensed in january 1988 to exploit :: commercially the fruits of the Viper work carried out at the Royal :: Signals and Radar Establishment at Malvern. :: :: Ron Davison, Teknis' business development manager, says, *We are :: looking for every comfort we can get from the development and :: suppliers of Viper:. :: :: Davison says the A$12m Australian railways project "is a world first" :: in the safety-critical market, making the first time that Viper has :: found a user outside the military and defence communities. :: :: Teknis' concern has been inspired by a series of reports in UK and US :: academic circles about RSRE and Charter's claims that Viper is :: formally verified for use in safety-critical applications where lives :: may be put at risk if the technology fails. :: :: Davison says he is "surprised at the sudden rash of reports about :: Viper coming out of the woodwork" 18 months after Teknis began work :: with the chip. :: :: But the report that is most critical of Viper, written by Avra Cohn of :: Cambridge University's computer laboratory, is two years old. It was :: published in May 1988 and delivered to RSRE, but Charter technologies :: claims it was not shown Cohn's findings until mid-1989. :: :: RSRE and Charter claim that Viper is formally specified, with a chip :: design which conforms to this specification. Cohn says in the report :: that this is misleading. :: :: "Such assertations, taken as assurances of the impossibility of design :: failure in safety-critical applications, could have catastrophic :: results," Cohn says in the report. :: :: The MoD says "It is a matter of interpretation of the words used to :: describe the dependabiliity of Viper. Nothing can be described as :: absolutely fail safe." :: :: This year a report by US consultants Computational Logic for US space :: agency Nasa says "Viper has not been formally verified" and lists four :: deficiences in RSRE's specification. In a draft copy of the same :: report dated June 1989, obtained by Computer Weekly, the former chief :: RSRE scientist on the Viper projects, John Cullyer, has indicated his :: agreement with Nasa's conclusions. Cullyer is now Professor of :: Electronics at Warwick University. :: :: The MoD cannot say whether the Nasa and Cohn reports have been looked :: at by RSRE staff, but a spokesman says, "Work is continuing to :: reinforce verification techniques and if a relevant report has been :: produced then it will be studied by scientists at RSRE." :: :: Marconi Electronic Devices of Lincoln, sub-contracted by the MoD to :: manufacture Viper hardware circuitry, is reining back on its :: commitment to the project while it waits for replies from the MoD. :: :: Tony Smith, Marconi Electronic Devices' integrated circuits contract :: manager, says the company "wanted a discussion with MoD and RSRE about :: what could be guaranteed for Viper. That meeting was due to take :: place this year, but the MoD cancelled it. We have still not had that :: meeting". :: :: Marconi has asked the MoD to respond to the Cohn and Nasa reports, but :: has not yet received a reply and has not been shown either of the :: reports, Smith says. The company is making prototype Viper circuits, :: but has no commercial orders. :: :: The Ministry of Defence would not comment on "confidential or :: commercial correspondence between it and third parties". :: :: The MoD says, "No Viper chip is known to have failed, but work is :: continuing to reinforce and improve verification techniques: on Viper, :: and that *although there are not known faults in the Viper design, an :: unremitting search for weakness must continue". :: :: ------------------------------ Date: Mon, 9 Jul 90 10:01:55 BST From: Martyn Thomas Subject: Cellphone risk to ABS? The following appears in an article advising against the use of cellular telephones in aircraft (it's illegal in most countries), published in Flight Safety Bulletin (the quarterly journal of the General Aviation Safety Committee in the UK): "As a point of interest, the manufacturers of some mobile telephones have issued a warning that they should not be used in cars fitted with an electronic anti-lock braking system (ABS) because the cellphone could cause the system to malfunction." Presumably the risk is from EMI. Does any RISKS reader have details on this? Is it just a precautionary warning to limit legal liability, or is there evidence? If this is a real risk, what about coaches, trains, other nearby vehicles ...? Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk ------------------------------ Date: Mon, 9 Jul 90 19:05:01 BST From: Tim Duncan Subject: Car phones and electronic systems The following is taken from an article by Kevin Eason in the (London) Times of July 9th: A safety alert has been issued to thousands of mobile telephone engineers after an incident in which a Jaguar car lost all power because of faulty telephone installation. The driver escaped safely when all electrical systems, including lights, brakes and engine, were shut down by a crossed wire. Jaguar drivers were warned yesterday to use only car phones fitted and checked by company dealers. The Federation of Communications Services has alerted its 350-member companies which handle mobile communications equipment that faulty installation could damage vital equipment, especially anti-lock braking systems (ABS), and urges them to check with manufacturer specifications. [...] The Jaguar driver involved was stranded on a motorway when all power to the car failed. Checks on the vehicle showed that a telephone engineer had crossed vital wires which caused a complete systems shutdown. Most new cars now have complex computer engine management systems and increasing numbers have electronic controls for suspension, brakes, gearbox and safety mechanisms. The new Mercedes SL convertible sports car, for example, has an automatic pop-up roll bar operated by computer. [...] Tim Duncan, AI Applications Institute, University of Edinburgh, 80 South Bridge, Edinburgh EH1 1HN, Scotland, United Kingdom. JANET: T.Duncan@uk.ac.edinburgh ARPA: T.Duncan%uk.ac.ed@nsfnet-relay.ac.uk BITNET: T.Duncan%uk.ac.ed@ukacrl.bitnet UUCP: ... mcvax!ukc!ed.ac.uk!T.Duncan ------------------------------ Date: Tue, 10 Jul 90 00:50:33 PDT From: joe@hanauma.stanford.edu (Joe Dellinger) Subject: Washington State Ferries slide into home I unfortunately had a Hertz rental car on Orcas Island, Washington, when a Washington State Ferry rammed the Island's only car ferry dock and knocked it out of service for a minimum of several days. The incident raised several interesting points: 1) Hertz had no category for this case; they repeatedly told us "If the car were broken, then you could fly off the island and get another car, and retrieving your car would be our problem. But since you say it isn't BROKEN, every day your car sits on the island is a day you are renting it... and of course if we have to pick it up there you get a retrieval fee, a fee for renting one-way, etc etc". 2) It would be interesting to get more informed information about how the ferries work. From the June 29, 1990 Seattle Times: "All indications point to a failure in the vessel's computer-control system. Inspectors will attempt to recreate the situation which caused the computer failure, but 'often these computer glitches have a tendency not to reappear'. ... The six Issaquah-class ferries ... were built in the late '70s and early '80s and have been plagued by propulsion-control problems. The system's top engineer in 1986 ... said then that the propulsion systems were so unpredictable that if he had his way he would replace them. Last year the state awarded a $550,000 contract ... to do design work for the ferry system, including modifications on the Issaquah-class propulsion- control system. ... Unlike the original propulsion system which controls and reverses the variable-pitch propellers on the diesel-engine ferries through a computer, the new system is simpler and more reliable ... ." From what I could gather from talking to the Seattle Times reporters covering the incident, the ferries have a "fly by wire" propulsion system that among other things does automatic docking. Occasionally the propulsion-control computer hiccups, locking the controls for a few seconds. Normally this is no bid deal, but in this case the computer system had the bad timing to hiccup just as the ferry was supposed to start braking for the final stage of docking at Orcas. As a result the ferry didn't brake at all and ploughed straight into the terminal, causing $250,000 in damage. (Also costing island merchants much of their July 4 weekend tourist revenue, and severely inconveniencing many unlucky tourists. We eventually managed to get our Hertz car off the island by private barge.) ------------------------------ Date: 16 Jul 90 08:48:19 PDT (Mon) From: jharkins@sagpd1.UUCP (Jim Harkins) Subject: Pentagon Pizza Driving to work this morning there was an interesting story on the radio. It seems the Domino's Pizza joint closest to the Pentagon can accurately predict when a major operation is about to take place. Evidently the planning meetings go on long into the night, and the best place to get food is Domino's. They interviewed someone from Domino's and he said that prior to the Panama invasion deliveries to the Pentagon jumped 25%. I'm glad I'm not in security..... ------------------------------ Date: Fri, 20 Jul 90 09:55:34 GMT From: Mark Smith Subject: Logica Code Slows Trident Organization: Canon Research Europe, Guildford, UK This is from the July 19 issue of Computer Weekly: The 9 billion pound Trident nuclear warhead programme is being held up because of serious problems with a computer system, developed by Logica, that keeps highly volatile nuclear materials apart during weapon assembly. The system, which ensures the safe movement and records the exact whereabouts of plutonium and other materials around two buildings at the Ministry of Defence's Atomic Weapons Establishment (AWE) at Aldermaston, is only able to handle half the volumes set by the MoD. Despite this, the system went live on July 13. [...] The system is a high integrity movement control package, using Stratus fault-tolerant hardware, used in A45 and A90, the two buildings at AWE involved in Trident development work. One source says that the MoD has set a target for the system to handle 200 units of nuclear material within the two buildings at any one time, but that the present system can only handle 100 units. The source says that the MoD and AWE have been revising the target downwards, but that Logica has been unable to meet the new figure. [...] A Logica spokeswoman says it is not company policy to comment on projects which have not been announced. Yes, this is the same Logica that ran into trouble during a project for San Fransisco's transit system. Mark Smith smith@canon.co.uk Canon Research Centre Europe ..ukc!uos-ee!canon!smith ------------------------------ Date: 19 Jul 90 08:02:29 PDT (Thursday) From: Rodney Hoffman Subject: GAO slams FAA computer systems According to a story by Jeffrey A. Perlman in the 'Los Angeles Times' 18 July 1990, the General Accounting Office has issued a new report entitled "Air Traffic control -- Inadequate Planning Increases Risk of Computer Failures in Los Angeles." The GAO says that in planning for a 1995 consolidation of Southern California radar tracking facilities, FAA officials have refused to consider computer solutions that could solve their computer problems because the agency does not want to rewrite or develop software to run on new, state-of-the-art hardware and expend the "additional time they believe would be required to undertake such an effort." A 1989 GAO report singled out the Los Angeles - Orange County air space as having the worst comuter-related aircraft tracking problems. The new report criticizes the FAA for ignoring the situation, saying air traffic controllers may find their radar screens flickering, showing insufficient data or blanking out at critical moments. FAA officials "are still analyzing the GAO report and had no formal reply." ------------------------------ Date: 22 Jul 90 11:03:45 PDT (Sunday) From: Rodney Hoffman Subject: BMW Drive-by-wire A short item in 'Business Week', July 30: BMW PUTS A BACKSEAT DRIVER ON A CHIP The latest cars offer a plethora of computerized wonders -- like chips that control the engine or warn you is a door is ajar. But would anyone want a computer that took over control of a car if it judged the vehicle was being driven too fast or improperly for road conditions? BMW engineers are betting the answer is yes. They've already installed an early version of their Heading Control system in cars at the auto company's research center in Munich. A camera above the rearview mirror tracks the center stripe and the line along the right side of the road. If a driver gets too close to either marker, a small electric motor integrated into the steering system is activated to put things right. Later versions will gauge road conditions and differentiate between broken and solid lines, so the computer can tell such things as whether it's okay to pass. Drivers being corrected might feel a tug on the wheel. But they can easily override the computer by continuing with wahtever they are doing. BMW engineers say the system is at least five years from market. And they predict that once customers get used to the idea, they'll love it. ------------------------------ Date: 19 July 1990 0829-PDT (Thursday) From: thode@nprdc.navy.mil (Walt Thode) Subject: British air defense computer suffers a "nervous breakdown" >From the Reuters news wire: BRITISH AIR DEFENSE COMPUTER SUFFERING A "NERVOUS BREAKDOWN" LONDON, Reuter - A nearly half-billion dollar computer designed to mastermind Britain's future air defenses won't be fit for action for another 10 years because of bouts of nervous confusion, Defense Ministry officials said Wednesday. The $448.8 million system known as ICCS -- Improved UK Air Defense Ground Environment Command and Control System -- was due to enter service in 1987. But officials told Parliament's defense committee the computer's problems with logic would delay operation by up to 10 years. "We get wrong answers sometimes and the bugs have to be tracked down and sorted out," Donald Spiers, who heads aircraft control at the ministry, told the committee. "Secondly, from time to time it crashes. What this means is the equivalent of a nervous breakdown. It becomes confused with the information and goes wrong." The production consortium, made up of Hughes Aircraft, Marconi and Siemens-Plessey, have upgraded the main computers driving the system to give more power, Spiers said. ICCS was designed as the sophisticated equivalent of the war tables used during World War II when model planes were pushed around a board. It will coordinate radar, fighters, surface-to-air missiles and air command centers through a single network. The system is being developed on a fixed price contract and Spiers said all extra costs had to be met by the consortium. He said the companies had not been paid for the past two years because of the problems encountered. --Walt Thode Internet: thode@nprdc.navy.mil UUCP: {everywhere_else}!ucsd!nprdc!thode ------------------------------ Date: Mon, 23 Jul 90 20:00:44 PDT From: Pete Mellor Subject: British Rail signalling software problem >From the Guardian, Mon. 23rd July, front page: Headline: BR signalmen 'worked blind' Subhead: Computer software problems admitted at key commuter train centre By-line: Patrick Donovan, Transport Editor British Rail has admitted that computer software problems have been uncovered at a signal centre which controls London's busiest commuter lines. They left operators "working blind" after train movements were wiped off control screens on at least one occasion over the last five weeks. A BR spokesman said newly installed software, responsible for flashing up the position of trains on the indicator screens of signal operators at Wimbledon, has been found to contain two technical faults. The Wimbledon centre controls 90 mph services south of Waterloo and includes the Clapham Junction area, where 35 people died in a train accident in December 1988. Faulty wiring on a signalling modernisation programme was found to have caused the crash. BR said one of the faults uncovered on the indicator screen software has not yet been fully rectified. An internal investigation began after an operator found that the system was providing "the wrong information". Realising that he had lost track of train movements, the operator immediately turned all signals to red. A spokesman said that at no time was any train at risk. "What happened caused concern to the signalman." But he stressed that the mechanical signal equipment and all other equipment worked normally, bringing all trains to an immediate standstill after the problem was discovered. "The problem was caused by computer software fault in the signal box. [sic - PM] It gave the wrong indication to the signal man. All the trains froze where they were. The lights told him that something was different to what was happening [outside]." BR conceded that the faulty equipment served a vital function, "this little piece of software tells the signalman what is happening outside". The software faults were found inside the panel in the train indicator box in a system responsible for operating the lights. Alastair Wilson, contracts and production director of E. B. Signal, the manufacturers, said: "The system is under test. I do emphasise that things are going through a testing stage. It is not unusual to have minor software bugs." [!!! - PM] A spokesman for the National Union of Railwaymen said that any operational shutdown of train indicator screens would "at best create a major disruption and at worst could create alarming safety hazards. If everything goes to red it puts enormous pressures on an individual signalman." [Remainder of article omitted. It goes on about unrelated signalling problems in the Clapham Junction area, including a loss of communication between Waterloo and Wimbledon signal centres, concern about the growing use of driver-only services on Network SouthEast, contradictions in the rule-book about whether or not such services may operate with a defective radio, and the need for the driver to draft competent members of the public to assist him in ensuring safety after an emergency stop.] A few comments: The report is rather confused, but it seems that the system receives information about the position of every train in the region, and displays this to the signalmen in the form of lights moving over a large indicator board. The bugs were in the hardware/software module which drives the display, so it was a case of "correct information in, garbage out". I wonder if the faulty module was rated as "safety-critical" in the hazard analysis. It would be nice to know *how* the signalman knew that he was being given wrong information, and what would have happened if he had not been so alert, and continued to operate the network with the wrong information. It is amusing to hear the manufacturer refer to a bug which brings an entire railway regional network to a standstill for some time as "minor". Perhaps he meant that only a few lines of code were in error! Somebody should have a word with him about how to classify faults and failures! If, as the manufacturer states, the system is under test, why was it being run to control live traffic without any back-up system? Surely BR's testing strategy can't be "Let the train take the strain"? (To quote one of their own advertising slogans!) Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB Tel.: +44 (0)71-253-4399 Ext. 4162/3/1 ------------------------------ Date: Thu, 26 Jul 90 14:39:51 -0700 From: Nancy Leveson Subject: Call for Papers on Testing, Analysis and Verification CALL FOR PAPERS Symposium on Testing, Analysis and Verification Victoria, British Columbia, Canada October 8-10, 1991 Sponsored by ACM Sigsoft The purpose of this meeting is to bring together researchers and practitioners who are working in the areas of software analysis, testing, and formal verification. Papers and panel session proposals are invited on current and emerging techniques, strategies, processes and tools for determining the presence or absence of errors in software and for inferring other characteristics of software quality. Papers should be a maximum of 5000 words in length. They should present a clear picture of the original contributions made by the paper, while also carefully relating the work presented to the work of others. The highest quality papers from the symposium may be considered for publication in a special issue or section of a research journal. Authors should send six copies of their paper or panel proposal to the Program Committee Chair, Nancy Leveson, at the address below. Papers must be received by March 1, 1991. Authors will be notified of acceptance by May 15, 1991. Camera-ready papers are due not later than July 1, 1991. Program Committee Victor Basili Mark Moriconi Stephen Schach Lori Clarke Mitsura Ohba Gene Spafford John Gannon Tom Ostrand K.C. Tai Susan Gerhart Dewayne Perry Elaine Weyuker Carlo Ghezzi Richard Platek Jack Wileden Richard Hamlet Debra Richardson Bill Young John Knight John Rushby Michal Young For other information concerning the symposium contact: General Chair Program Chair Prof. William Howden Prof. Nancy Leveson Computer Science Dept. Computer Science Dept University of California University of California La Jolla, California 92093 Irvine, California 92717 USA USA (619) 534-2723 (714) 856-5517 ------------------------------ End of RISKS-FORUM Digest 10.15 ************************