Proceeding of the 33rd European Safety and Reliability Conference
This paper discusses the input documents and project decisions that are important when developing... more This paper discusses the input documents and project decisions that are important when developing a safety case. The discussion is based on interviews with seventeen companiesall engaged in building safety cases for commercial products. The majority of the companies are Norwegian and Swedish. However, we have also interviewed companies from Denmark, UK, USA and Turkey. We discuss issues such as when in the project to start developing a safety case, what are the important inputs needed, and what are the roles of the required standards. Some issues will not be includede.g. AI systems. The main reason for this is that none of the companies we interviewed developed AI systems. We also discuss important issues such as the purpose of the safety case, safety case maintenance and the role of reuse when developing a safety case. We will also discuss the relationships between safety case and trust case and how a safety case can be used in communication and to build trust in a system. Our further work will focus on two important areastraceability between the system and safety case, which is important in order to keep the safety case up to date during system changesand the possibility of expanding the "case" idea to bridge the communication gap between software developers and customers or users.
This paper discusses reactive improvement of clinical software using methods for incident analysi... more This paper discusses reactive improvement of clinical software using methods for incident analysis. We used the "Five Whys" method because we had only descriptive data and depended on a domain expert for the analysis. The analysis showed that there are two major root causes for EHR software failure, and that they are related to human and organizational errors. A main identified improvement is allocating more resources to system maintenance and user training.
expression of several important genes in different organs under certain conditions. 7,8 However, ... more expression of several important genes in different organs under certain conditions. 7,8 However, the role of the vascular intrinsic clock in the regulation of vascular contractility and its molecular mechanisms still remain elusive. Background-The circadian variation in the incidence of cardiovascular events may be attributable to the circadian changes in vascular contractility. The circadian rhythm of vascular contractility is determined by the interplay between the central and peripheral clocks. However, the molecular mechanism of the vascular intrinsic clock that generates the circadian rhythm of vascular contractility still remains largely unknown. Methods and Results-The agonist-induced phosphorylation of myosin light chain in cultured smooth muscle cells synchronized by dexamethasone pulse treatment exhibited an apparent circadian oscillation, with a 25.4-hour cycle length. The pharmacological inhibition and knockdown of Rho-associated kinase 2 (ROCK2) abolished the circadian rhythm of myosin light chain phosphorylation. The expression and activity of ROCK2 exhibited a circadian rhythm in phase with that of myosin light chain phosphorylation. A clock gene, RORα, activated the promoter of the ROCK2 gene, whereas its knockdown abolished the rhythmic expression of ROCK2. In the mouse aorta, ROCK2 expression exhibited the circadian oscillation, with a peak at Zeitgeber time 0/24 and a nadir at Zeitgeber time 12. The myofilament Ca 2+ sensitization induced by GTPγS and U46619, a thromboxane A2 analog, at Zeitgeber time 0/24 was greater than that seen at Zeitgeber time 12. The circadian rhythm of ROCK2 expression and myofilament Ca 2+ sensitivity was abolished in staggerer mutant mice, which lack a functional RORα. Conclusions-ROCK2 plays a pivotal role in generating the intrinsic circadian rhythm of vascular contractility by receiving a cue from RORα. The ROCK2-mediated intrinsic rhythm of vascular contractility may underlie the diurnal variation of the incidence of cardiovascular diseases. (Circulation. 2013;126:104-114.)
The TrustMe project develops a safety case for autonomous buses. A safety case is mostly based on... more The TrustMe project develops a safety case for autonomous buses. A safety case is mostly based on information from the developers and refers to one or more relevant safety standards. The bases for a safety case are the defined safety standards and proof of compliance, based on the paper trails left by each required activity. A trust case is different and trust and safety assessments are not necessarily correlated. In order to make self-driving buses a success they need to be considered trustworthy. Thus, we need a "Trust case". To ensure that the vehicles are safe and to inform the public, we have developed both a developer safety case and safety case for the public. To take care of the remaining factors we have developed a "Trust case". The trust case has been developed as part of literature studies, surveys and interviews. We have made a survey of 311 passengers and interviewed 18 autonomous bus passengers. Based on literature studies, surveys and interviews, we have proposed a set of issues that should be included into a "Trust case". By providing the public with a "Trust case" together with a "safety case for the public" we will help manufacturers of autonomous vehicles and operators to gain public trust.
Proceedings of the 19th International Conference on Agile Software Development: Companion
In this paper, we report on a small experiment to compare HazId and hazard stories. The experimen... more In this paper, we report on a small experiment to compare HazId and hazard stories. The experiment is performed using fourth year computer science students analysing a simple version of a train control system. The purpose of the experiment was two-fold - see if the students could use the hazard stories in an efficient way and to compare the results of the two approaches HazId and hazard stories. In addition to the experiment, we also will discuss how the hazard story fit in with an agile development process.
SafeScrum® – Agile Development of Safety-Critical Software, 2018
This chapter lays out the basis for SafeScrum ® and discuss the iterative and incremental develop... more This chapter lays out the basis for SafeScrum ® and discuss the iterative and incremental development process. In addition, we describe the details in SafeScrum ® , such as: The associated roles. Fundamental SafeScrum® concepts. How to prepare a SafeScrum® project.
This chapter highlights important research in all areas covered by SafeScrum ® : Requirements, te... more This chapter highlights important research in all areas covered by SafeScrum ® : Requirements, testing and code refactoring. Continuous integration, iterative processes and customer involvement. Planning and traceability. What will happen in these areas in the near future.
What This Chapter Is About Most of the relevant roles when developing signalling systems Assessme... more What This Chapter Is About Most of the relevant roles when developing signalling systems Assessment performed by the assessor The accreditation system and notification of bodies Authorisation performed by the safety authority
Proceeding of the 33rd European Safety and Reliability Conference
This paper discusses the input documents and project decisions that are important when developing... more This paper discusses the input documents and project decisions that are important when developing a safety case. The discussion is based on interviews with seventeen companiesall engaged in building safety cases for commercial products. The majority of the companies are Norwegian and Swedish. However, we have also interviewed companies from Denmark, UK, USA and Turkey. We discuss issues such as when in the project to start developing a safety case, what are the important inputs needed, and what are the roles of the required standards. Some issues will not be includede.g. AI systems. The main reason for this is that none of the companies we interviewed developed AI systems. We also discuss important issues such as the purpose of the safety case, safety case maintenance and the role of reuse when developing a safety case. We will also discuss the relationships between safety case and trust case and how a safety case can be used in communication and to build trust in a system. Our further work will focus on two important areastraceability between the system and safety case, which is important in order to keep the safety case up to date during system changesand the possibility of expanding the "case" idea to bridge the communication gap between software developers and customers or users.
This paper discusses reactive improvement of clinical software using methods for incident analysi... more This paper discusses reactive improvement of clinical software using methods for incident analysis. We used the "Five Whys" method because we had only descriptive data and depended on a domain expert for the analysis. The analysis showed that there are two major root causes for EHR software failure, and that they are related to human and organizational errors. A main identified improvement is allocating more resources to system maintenance and user training.
expression of several important genes in different organs under certain conditions. 7,8 However, ... more expression of several important genes in different organs under certain conditions. 7,8 However, the role of the vascular intrinsic clock in the regulation of vascular contractility and its molecular mechanisms still remain elusive. Background-The circadian variation in the incidence of cardiovascular events may be attributable to the circadian changes in vascular contractility. The circadian rhythm of vascular contractility is determined by the interplay between the central and peripheral clocks. However, the molecular mechanism of the vascular intrinsic clock that generates the circadian rhythm of vascular contractility still remains largely unknown. Methods and Results-The agonist-induced phosphorylation of myosin light chain in cultured smooth muscle cells synchronized by dexamethasone pulse treatment exhibited an apparent circadian oscillation, with a 25.4-hour cycle length. The pharmacological inhibition and knockdown of Rho-associated kinase 2 (ROCK2) abolished the circadian rhythm of myosin light chain phosphorylation. The expression and activity of ROCK2 exhibited a circadian rhythm in phase with that of myosin light chain phosphorylation. A clock gene, RORα, activated the promoter of the ROCK2 gene, whereas its knockdown abolished the rhythmic expression of ROCK2. In the mouse aorta, ROCK2 expression exhibited the circadian oscillation, with a peak at Zeitgeber time 0/24 and a nadir at Zeitgeber time 12. The myofilament Ca 2+ sensitization induced by GTPγS and U46619, a thromboxane A2 analog, at Zeitgeber time 0/24 was greater than that seen at Zeitgeber time 12. The circadian rhythm of ROCK2 expression and myofilament Ca 2+ sensitivity was abolished in staggerer mutant mice, which lack a functional RORα. Conclusions-ROCK2 plays a pivotal role in generating the intrinsic circadian rhythm of vascular contractility by receiving a cue from RORα. The ROCK2-mediated intrinsic rhythm of vascular contractility may underlie the diurnal variation of the incidence of cardiovascular diseases. (Circulation. 2013;126:104-114.)
The TrustMe project develops a safety case for autonomous buses. A safety case is mostly based on... more The TrustMe project develops a safety case for autonomous buses. A safety case is mostly based on information from the developers and refers to one or more relevant safety standards. The bases for a safety case are the defined safety standards and proof of compliance, based on the paper trails left by each required activity. A trust case is different and trust and safety assessments are not necessarily correlated. In order to make self-driving buses a success they need to be considered trustworthy. Thus, we need a "Trust case". To ensure that the vehicles are safe and to inform the public, we have developed both a developer safety case and safety case for the public. To take care of the remaining factors we have developed a "Trust case". The trust case has been developed as part of literature studies, surveys and interviews. We have made a survey of 311 passengers and interviewed 18 autonomous bus passengers. Based on literature studies, surveys and interviews, we have proposed a set of issues that should be included into a "Trust case". By providing the public with a "Trust case" together with a "safety case for the public" we will help manufacturers of autonomous vehicles and operators to gain public trust.
Proceedings of the 19th International Conference on Agile Software Development: Companion
In this paper, we report on a small experiment to compare HazId and hazard stories. The experimen... more In this paper, we report on a small experiment to compare HazId and hazard stories. The experiment is performed using fourth year computer science students analysing a simple version of a train control system. The purpose of the experiment was two-fold - see if the students could use the hazard stories in an efficient way and to compare the results of the two approaches HazId and hazard stories. In addition to the experiment, we also will discuss how the hazard story fit in with an agile development process.
SafeScrum® – Agile Development of Safety-Critical Software, 2018
This chapter lays out the basis for SafeScrum ® and discuss the iterative and incremental develop... more This chapter lays out the basis for SafeScrum ® and discuss the iterative and incremental development process. In addition, we describe the details in SafeScrum ® , such as: The associated roles. Fundamental SafeScrum® concepts. How to prepare a SafeScrum® project.
This chapter highlights important research in all areas covered by SafeScrum ® : Requirements, te... more This chapter highlights important research in all areas covered by SafeScrum ® : Requirements, testing and code refactoring. Continuous integration, iterative processes and customer involvement. Planning and traceability. What will happen in these areas in the near future.
What This Chapter Is About Most of the relevant roles when developing signalling systems Assessme... more What This Chapter Is About Most of the relevant roles when developing signalling systems Assessment performed by the assessor The accreditation system and notification of bodies Authorisation performed by the safety authority
Uploads
Papers by Tor Stålhane