Safety analysis plays an important role in developing safety-critical systems. It aims at deriving safety requirements throughout the safety-critical system’s development lifecycle martins2017requirements . By performing safety analysis, potential causes of accidents can be identified, eliminated or controlled in design or operation before damage occurs leveson2011engineering . Due to an inherently complex nature of safety-critical systems, safety analysis concentrates not just on single component or function failures, but rather analysing from a system viewpoint including component interactions, cognitive complex human decision-making errors, social, organisational and management factors leveson2011engineering .
In safety-critical systems’ organisation management, safety analysis is changing from individual tasks, which are mainly performed in the development team, to joint work with an alignment of multiple functional departments or external organisations, such as customers or suppliers martins2017requirements . Safety requirements need to be provided by customers to the development team, while detailed safety information of products need to be provided from suppliers to original equipment manufacturers (OEMs). Among the stakeholders during safety analysis, communication occurs across different channels.
Leveson mentioned: “Risk perception (in safety analysis) is directly related to communication and feedback. The design of communication channels must be considered." leveson2011engineering (P.424). In the automotive domain, experts mentioned in the standard: “The organisation should institute, execute and maintain processes to ensure that identified functional safety anomalies are explicitly communicated to responsible persons" iso26262 (Part 2, P.13). In the nuclear power domain, experts mentioned that: “Communication should be honest and open when answering to safety-related questions" reiman2009evaluating (P.53). In the aviation domain, experts mentioned: “Projects should plan for the appropriate level of technical oversight to ensure communication." rierson2017developing (P.528). It requires communication among team members, with the certification authority and customers. Therefore, in the safety-critical industries, the organisation management should promote effective communication channels during safety analysis at all levels.
However, in practice, communication channels during safety analysis are uncultivated martins2017requirements . Using formal documentation is a classic way during safety analysis to complement communication vilela2017integration . It ensures a correct and complete information transfer. However, at present, the market of safety-critical systems is becoming fast-changing. The increasingly incoming customer requirements are captured by face-to-face communications hummel2013role . These informal communication channels are arbitrarily used by practitioners and not regulated by relevant authorities. Thus, we support Keyton’s doi:10.1146/annurev-orgpsych-032516-113341 and Kraut et al.’s kraut1990informal views that an exploration of the existing communication channels during safety analysis becomes necessary, including their types, their usage frequencies as well as their purposes.
- RQ 1
Which communication channels are adopted for safety analysis?
- RQ 2
How frequently used are safety analysis communication channels?
- RQ 3
Which are the purposes of safety analysis communication channels?
Furthermore, communication channels during safety analysis are problematic hummel2013role . Practitioners in safety-critical industries notice their negative impacts from various perspectives, such as a poor management (an overwhelming amount of information and a loss of details) of safety analysis related information reiman2015principles or little support for requirements engineering (a non-standardisation of nomenclature, the incompleteness of safety requirements and a lack of tool support) vilela2017integration . Yet, as called by Dobson et al. lrsc , Vilela et al. vilela2017integration and Kraut et al. kraut1990informal , scarce research explores the challenges in communication channels during safety analysis.
- RQ 4
Which are the challenges when using safety analysis communication channels?
1.1 Research Objectives
In this article, the overall purpose is to investigate communication channels during safety analysis. First, we investigate the existing communication channels including their frequencies among multiple functional departments. Furthermore, we address their purposes in connection to the existing communication channels. Finally, we derive the top 10 challenges and map them with the aforementioned purposes.
In this article, we have the following contributions:
We find 9 popular communication channels including their usage frequencies during safety analysis. We notice that safety-critical systems have strict regulations and the communication cannot be in public. Thus, the number of used communication channels is small. Yet, these 9 communication channels lay a foundation for further research. Most of them are frequently used at a 1-4 times per week rate.
We address 28 purposes based on the 9 communication channels during safety analysis. Although the number of communication channels during safety analysis is small, the purposes are diverse yet accountable.
We provide the top 10 challenges in the communication channels during safety analysis and map them with the 28 purposes. We highlight a possible way to select communication channels for achieving different purposes. The general challenges have specific manifestations as well as countermeasures when using different channels serving different purposes.
The article is organised as follows. In Section 2, we describe the background of communication channels and the related work regarding our study. We define a theoretical lens of communication channels during safety analysis in Section 3. Section 4 presents the case study design including context, research questions, data collection and analysis procedures. In Section 5, we report our study results. We discuss our implications and limitations in Section 6, before concluding our article in Section 7.
2 Background and Related Work
2.1 Communication channels in traditional organisation management
Background: Communication channels in organisation management is a wide-ranging topic, which demonstrates how people use verbal and nonverbal messages to generate meanings within and across various contexts, cultures and media doi:10.1146/annurev-orgpsych-032516-113341 . Keyton doi:10.1146/annurev-orgpsych-032516-113341 concluded a literature study by describing practical implications of areas concerning communication in organisation management. He summarised the theories from a philosophical perspective, such as a system theoretical approach, which depicts that messages are created, delivered and received by individuals in a complex web of relationships (safety analysis happens in a complex environment in industry), as well as a critical culture perspective, which points out that critical work encourages the exploration of alternative communication practices that allow greater democracy (safety analysis, as a critical factor, endures great influences from safety culture). In addition to the theories, the author posed future research questions, such as (1) What are effective ways for team members from different professions to develop shared meaning? To perform safety analysis, a common understanding should be established among stakeholders. (2) How do culture of organisations and politics influence employees (mis)use of technology? The execution of safety analysis is strongly influenced by safety culture and politics. In practice, communication channels are used with diverse taxonomies, such as verbal or nonverbal, synchronous or asynchronous and internal or external. Johnson et al. johnson1994differences investigated how to determine the use of communication channels in different taxonomies by conducting 380 surveys in a large midwestern state governmental agency. The authors mentioned that to use formal or informal communication channels, perceived applicability, output’s effect and cultural norms are three possible criteria. Traditional safety-critical systems have a preference for formal communication to ensure preciseness bowen1993safety . Yet, many informal communication channels arise currently in safety-critical industries.
Related work: Storey et al. storey2017social focused on communication channels in organisation management during software development. They conducted a large-scale survey with 1,449 GitHub users to discuss the channels that the developers find essential to their work and gain an understanding of the challenges they face using them. 16 challenges are proposed under developer issues, collaboration and coordination hurdles, barriers to community building and participation, social and human communication, affordances, literacy and friction and content and knowledge management. Safety analysis intertwines with software development. Some of these challenges do exist during safety analysis in our context, such as geographic problems. Yet, they differ from manifestations. In software development, the authors considered geographic problems due to different time zones. An effective communication software, such as Slack, can reduce this problem. However, during safety analysis, geographic problems influence safety analysis information transmission and safety knowledge sharing. A pure communication software cannot solve this problem with respect to safety culture fundamentally. Kraut et al. kraut1990informal investigated a use of informal communication channels in an R&D organisation management through an experiment in which two small work groups were compared. The locations, the usage frequencies and the duration of informal communication are depicted with practical examples. They believed that in R&D organisations, informal communication is keen to enhance collaborations and increase projects’ success rates. During safety analysis, communication is becoming informal. Yet, these informal communication channels have not been considered as a way to improve collaborations.
2.2 Communication channels in modern organisation management
Background: Modern software development processes are moving from heavy-weight with a huge amount of documents, to light-weight, with much oral communication. Communication channels receive more attention from practitioners cockburn2002agile whitehead2007collaboration . They advocate that face-to-face conversation is the best form of communication alliance2001agile . The practical activities encompass pair programming williams2002pair to enhance communication between developers or stand up meetings schwaber2002agile to enhance communication among team members. Thus, the research concerning communication design or the importance of social skills are arising in modern organisation management. They are considered as a factor influencing team work quality and project success lindsjorn2016teamwork .
Related work: Pikkarainen et al. pikkarainen2008impact conducted a case study in F-Secure with two agile software development projects. The authors explored challenges focusing on internal and external communication. Since the groups are becoming self-organised in their research context, the communication among team members and between team members and customer, management, support group, enterprise staff show increasing challenges, such as a lack of coordination martini2016multiple and a non-deterministic decision-making process conboy2017examining . Hummel, Rosenkranz and Holten hummel2013role conducted a systematic literature review with 333 relevant papers on agile software development and communication. They discussed the results from three directions: Input including team distribution, team size, project domain; Output including software development success; Agile software development including extreme programming (XP) and Scrum. The authors noted that the project domain poses specific issues on communication channels, such as safety or security-critical systems which rely on documentation, yet the changing requirements are not well documented. Moreover, when developing complex systems, there are lapses of memory which negatively influence communication. Safety-critical systems development is becoming light-weight staalhane2012application . In particular, an integrated safety analysis happens more frequently. Special attention is needed in organisation.
2.3 Communication challenges in safety-critical systems
Background: Developing or operating safety-critical systems encompasses specific communication challenges. Dobson, Moors and Norris lrsc conducted a literature review concerning the communication in safety-critical systems by illustrating examples like tragic loss in an Esso gas plant explosion in 2001 (a combination of ineffective communication and inadequate hazard assessment), fire in a ship called Scandinavian Star in 1990 (a lack of communication between rescue co-ordination and passengers) and the Tenerife Airport Disaster in 1979 (misinterpretation by the Captain of the aircraft). The authors pointed out that (1) there is a link between communication and safety, (2) there is a range of mechanisms by which communication can fail, (3) there is a range of factors that shape the safety of communications, (4) formal, structured communication is most effective but needs to be use appropriately. Some possible communication problems contain missing, unnecessary, inaccurate, poor quality and ambiguous information. Improvements might be a careful specification, a moderate cutting-down, the utilisation of aids such as logs, the development of communication skills and the setting of standards for effective and safe communication prineas2010safety . Some instinct causalities have been investigated. Flin et al. flin2008safety classified these causalities into internal and external factors in their book. Internal factors can be attributed to characteristics of individuals, while external factors can be attributed to environments. Gibson gibson2007 identified five key elements by conducting a literature review, which include (1) the communication process of sender-medium-receiver, (2) the goals of the communication process, (3) the language used in the communication process, (4) the context of communication, and (5) individual factors. There are further recommendations in terms of explicitness, timing, assertiveness and active listening to improve communication in organisations flin2008safety . These articles demonstrated a link between communication and safety-critical issues, as well as the specific elements and recommendations in safety-critical industries compared to the general communication in organisation management.
Related work: Vilela et al. vilela2017integration conducted a systematic literature review with 57 papers to investigate the communication between requirements engineering and safety engineering (including safety analysis). The research questions concern the activities, techniques, information artifacts, tools and benefits of performing safety analysis in connection with requirements engineering. 36 activities were listed by the authors. They mentioned that during these activities, no unified vocabulary among stakeholders hampers the communication. The techniques are illustrated by taxonomies, such as inductive/deductive and qualitative/quantitative. These taxonomies are considered to reduce the gap in communication between requirements engineering and safety engineering. Safety requirements are the main information through communication, which include safety-significant requirements and pure safety requirements as well as accidents, hazards, risks and harms. To promote an effective communication, practitioners should create an agreed-upon vocabulary and semantic structure containing all the relevant concepts, their relations and axioms within the safety domain for the purpose of exchanging information and facilitating reasoning. 66.67% of the studies do not cite the use of tools. A lack of tools would lead to missing a sufficient guidance for execution and communication in safety analysis. Thus, it is worth noticing that an effective communication in safety analysis can reduce errors in requirements specification, improve system safety, help design, reduce costs and time, improve cooperation, enhance traceability, better present safety information, reduce workload, reduce interface faults, increase confidence and allow user feedback.
3 Communication in Safety Analysis
We define a theoretical lens of communication in safety analysis. We refer to the standards ISO 26262, ISO 14971 and IEC 60601 concerning the execution of safety analysis in safety-critical systems, as well as several internal safety analysis standards.
Safety analysis happens primarily in four stages in the development of safety-critical systems. (1) At the beginning, a safety expert (he or she could be a functional safety manager, external safety expert or internal safety expert) together with other project members, who are responsible for facing customer projects, derive system-level safety requirements. Popular techniques are Hazard and Operability Analysis (HAZOP), Hazard Analysis and Risk Assessment (HARA) and Fault Tree Analysis (FTA). (2) After architectural design, the safety expert, development teams and other stakeholders derive detailed safety requirements and implement them in development. Popular techniques are Failure Mode and Effect Analysis (FMEA) for software and Failure Modes, Effects and Diagnostic Analysis (FMEDA) for hardware. (3) A verification, such as model checking, is necessary for testing the detailed safety requirements. (4) A validation, such as a review, is done by the deployment department or customers to test the system-level safety requirements. In addition to these four stages, safety analysis might happen during change impact analysis when there is a changing request. The concrete execution of safety analysis depends on whether they aim to develop a new product or reuse a product.
The theoretical lens is shown in Figure 1. The communication encompasses internal communication and external communication. We simplify the roles in the development team with one internal safety expert, who mainly performs safety analysis, and other team members, which include architects, developers, testers and so on. The internal communication happens between the internal safety expert and other team members. Besides the development team, the industries also establish a functional safety department, which takes responsibility for the whole functional safety issues at the company level. In the functional safety department, a functional safety manager fixes mainly the external affairs and monitoring the execution of standards, while an external safety expert keeps contact with the internal safety expert to conduct training or knowledge sharing. In industry, the safety analysis related collaborative activities, such as execution and review, are guided by a safety analysis moderator, who is from a technical support department. The moderator ensures an official procedure to perform safety analysis. To ensure the safety assurance capability concerning process execution, the industries perform safety audit/assessment periodically by a safety auditor or assessor. It happens two to three times per year, especially when there is a deliverable product. The communication happens also between the development team and project manager, customers, suppliers and other non-functional departments, when the safety analysis issues concern project-level, product-level, purchasing or sales.
4 Case study design
We chose an exploratory case study design as proposed by Runeson et al. runeson2012case . We conducted this case study in an inductive way by designing the theoretical lens in Figure 1. The reasons are: (1) There is no existing theory on communication channels during safety analysis, such as the possible channels and using regulations. (2) The exploration scope is indeterministic in terms of communication channels in safety analysis due to an omnicooperation. (3) The boundaries of safety analysis activities need to be clear for investigating communications, since some of them are blurred within development activities. This theoretical lens can provide us a clear boundary of our article and lay a foundation for our results.
|A||Large||Germany||Automotive||Automotive parts; Power tools; Electronics; Motorised bicycle motors.||400,500||3|
|A1||Medium||China||Automotive||Automotive parts; Power tools; Electronics; Motorised bicycle motors.||59,000||26|
|A2||Medium||China||Automotive||Gasoline engine management systems; Transmission control system; Hybrid and electric drive control system.||9,400||19|
|A3||Medium||China||Automotive||Diesel systems for passenger cars, light and heavy commercial vehicles.||1,800||3|
|B||Large||Germany||Medical Equipment||CT/SPECT scanner; Angiography; X-ray products; Molecular diagnostics.||372,000||4|
|C||Medium||Germany (Italy)||Automotive||Automotive lighting; Powertrain; Suspension systems; Motorsport.||43,000||3|
|D||Small||Germany||Industrial 4.0 Based Product System||Technical strategy for production; ICT for manufacturing; Communication for factories; Process planning.||Less than 100 (unstable)||2|
We conducted a multiple case study in seven safety-critical companies (three of which are subsidiaries of company A), as we can see in Table 1. We selected company A, together with A1, A2 and A3, as our biggest sample (with overall 51 participants). To cover different sizes of companies, we included company C (medium) and company D (small). To expand our research domains (company A is an international automotive industry), we included company B (an international medical equipment industry) and company D (a local industry 4.0 based production system). The duration of the investigated projects varies from 6 months to 3 years. The safety assurance processes of them follow ISO 26262 (automotive), VDA (automotive), Automotive SPICE, ISO 14971 (medical equipment), ISO 15004 (medical equipment) and IEC 60601 (medical equipment). The safety analysis is following the internal standards of FMEA, FTA and HAZOP. The investigated projects encompass functional development of ECU (Electronic Control Unit), NCU (New energy Control Unit) and body electronic control units, remote monitoring of CT machines and software services for smart factories.
We have in total 60 participants. 39 participants took part in the surveys, while the other 21 participants took part in the interviews. We asked the 21 interviewees before the interviews to ensure that they have not answered the surveys before. Their working experiences in safety-critical industries range from 1 to 23 years. As shown in Figure 2, most participants are quality assurance engineers and managers. 17 participants are from the quality assurance (QA) department. 10 participants are from the functional safety department. There are 23 managers and 3 experts. Other roles are 9 developers, 1 analyst and 2 leaders, as well as 1 participant in sales, 1 participant in purchasing and 1 participant in production department.
4.2 Data collection
As we can see in Figure 3, we conducted three rounds of data collection incrementally. In the first round, we ran surveys in seven companies between 2017-09-01 and 2017-10-31 to investigate the existing communication channels as well as their usage frequencies. In the second round, we conducted semi-structured interviews and documentation reviews in seven companies separately between 2017-09-01 and 2017-10-31 and between 2017-12-01 and 2018-01-31 to investigate their purposes and challenges. In the third round, from 2017-12-18 to 2018-01-05, the first author participated in several safety analysis meetings and the daily work in a functional safety department. The duration of participant observation is three weeks in company A2. Before data collection, we pre-interviewed several experts from four companies, either by telephone or by a face-to-face introductory meeting, to look through the organisation structure, decide on a common objective, establish agreements and help designing the surveys and interview questions. Each interview lasted one hour. These experts were further arranged to be the representative of each company.
In the first round, we used a survey to collect both qualitative and quantitative data, which cover the participant’s background (positions, working years, the descriptions and durations of the running projects), the existing communication channels and the frequencies of using each communication channel. We sent the link to each representative via email, as well as the survey in electronic form to ensure that all the participants receive them. Since the investigation including the questions and predictable answers are sensitive in safety-critical systems, we decided to hand out the surveys through a company representative. This leads to a limited number of participants, which poses a challenge. During these two months, the first author checked the progress every two weeks through communicating with the representatives by videophone regarding the distribution of the surveys, as well as problems and feedback.
In the second round, we used semi-structured interviews to investigate the purposes and challenges of the communication channels. We selected firstly the communication channels from the results in the first round. We asked the interviewees to indicate possible additional communication channels as the first question. Moreover, we asked for the possible purposes of each communication channel. We went deeper to gain some real examples. The results may refer to product and customers’ information, we keep them confidential. Lastly, we inquired about the challenges. We explained that the challenges they found could be specific to one communication channel, or in a general way across multiple channels. To make each challenge clear, we asked further in-depth sub-questions depending on participants’ answers, such as “Who are the senders and receivers?", “What are the possible effects?", “How serious are the effects?", “What are the causal factors?", “How do you treat or fix this challenge?". We listed some possible in-depth sub-questions in the interview guide. Meanwhile, the first author reviewed the documents, which are related to the communication that happens during safety analysis, such as R&D process instruments including safety analysis activities or interfaces in R&D process, product development reports including the safety part of product development and quality management reports including safety quality management, quality management handbooks, R&D risk management instructions, FMEA, FTA and HAZOP guidelines and working instructions, decision analysis and making reports and technical review reports. We inspected their contents, structures and relevant senders (editors) and receivers (readers or users) to analyse aspects such as “Are the contents fully written and could they be easy to understand by the receivers (readers and users)?", “Are they clearly structured by the senders (editors)?" and “How long do the documents need to be looked through and be used?"
In the third round, the first author conducted a direct observation in company A2. The first author took part in several team meetings such as a meeting concerning a comparison between the existing safety analysis procedure and a new version of ISO 26262, a meeting to discuss how safety analysis is executed in software and hardware development and how to coordinate with cyber-physical security. The first author observed the daily work in a functional safety department (she sat near to an internal safety expert who performed the safety analysis). Apart from the regular processes such as “How frequently does the internal safety expert communicate?", the first author observed also the internal safety expert’s verbal communication with the functional safety manager, developers and stakeholders in non-functional departments, as well as the non-verbal communication, such as the internal safety expert’s field notes, which recorded some outputs from communication. In the following section, we present how we analyse our data.
4.3 Data analysis
To start answering our research questions, we investigate the participants’ qualifications, such as positions, working experiences and running projects.
For qualitative data, we consider basic coding steps and follow the logic of grounded theory coding strauss1994grounded . To start with, we conduct open coding to keep initial coding open-ended without having any preconceived concepts. Since the topic concerning communication channels has a wide range, even in safety analysis activities, open coding seems the most appropriate way to record transcripts line-by-line. Furthermore, based on an initial coding process, we get first categories. We list a preliminary category and conduct a selective coding. We focus on the codes relating to complementing the existing communication channels for RQ 1 and complementing the frequencies of using each communication channel, their purposes for RQ 3 as well as their challenges for RQ 4. The selective coding process is emergent and iterative. We compare the codes and refine our categories. For example, in terms of RQ 1, some interviewees mentioned that the communication channels lack a clear clarification, such as “If a personal meeting with two people is a formal meeting or personal discussion?" We discuss the bias separately with an expert in company A to complement the results. In terms of RQ 2, after the first round of selective coding, some purposes show similarities, such as “We use email to inform a temporary meeting" and “We call the colleagues to fix an emergent complaint", we group them as “A real-time notification". In addition, there is one sentence of code that encompasses two or more sub-purposes, such as “We go directly to the sales or deployment (the contact person) to organise a meeting when there comes a temporary but emergent customer’s complaint". It is divided into “Fix customers’ complaints" and “Cooperate among multiple functional departments". We conduct a second round of selective coding to group similar purposes and divide mixed purposes. The same holds for RQ 4 concerning challenges.
Lastly, to connect our results concerning the four RQs coherently, we conduct axial coding for RQ 1, RQ 3 and RQ 4. We link the existing communication channels with their purposes. We link the top 10 challenges with their purposes as well. We demonstrate an example of our coding phase including interview snippet, open coding, selective coding and axial coding in Table 2.
|Interview snippet||Open coding||Selective coding
Q: “What are the common purposes to facilitate communication concerning safety analysis?"
A: “…we have to exchange (safety analysis) information with our parent company…but the documents are always missing … The functions are inherited, detailed architecture design documents are kept by them … safety analysis cannot be done without considering interfaces with original products …"
|We exchange safety analysis information with our parent company. The documents are missing. The functions are inherited. Detailed architecture design documents are kept by them. Safety analysis cannot be done without considering interfaces with the original products.||
Purposes: Derive safety requirements.
PURPOSES_Derive safety requirements_Share knowledge.
Q: “Have you noticed some challenges in these communication channels?"
A: “…more importantly, we do care about the confidentiality. We categorised the data related to safety analysis with different confidential levels. High confidential data requires relevant authorities to read or transmit …"
|We care about confidentiality problem. We categorise the safety analysis related information with different confidential levels. High confidential levels’ data need authorities to read and transmit.||
Purposes: Transfer safety requirements.
Challenges: Transmission of confidential information.
PURPOSES _Transfer safety requirements
CHALLENGE_Confidential information_Authority problems.
For quantitative data concerning RQ 1, we choose pure numbers of participants to represent the utilisation of each communication channel. For quantitative data concerning RQ 2, in the first round, the participants scored the frequencies of the occurrences of each communication channel. The scale ranges from 1-4 times per day to 1-4 times per year. We consider that only the pure numbers in the surveys might show memory lapses hummel2013role , the same as by asking the interviewees, a direct observation is necessary to validate the results.
5.1 RQ1: Which communication channels are adopted for safety analysis?
As we can see in Figure 4, we find 9 communication channels during safety analysis, which are meetings, personal discussion, internal communication software (private), email, telephone, documentation, project coordination tools, training (including tutorial) and boards. Few participants mentioned the use of social communication software. However, considering that it is a rare and non-regulated case111We consider that it is due to a culture difference between Europe and Asia. More descriptions are shown in Section 6.2., we discussed with an expert in company A and decided not to include it in our results. We summarise the results as follows:
Meeting: All the 39 participants (100%) mentioned meeting as a main communication channel during safety analysis. A meeting is defined as a gathering of two or more people that has been convened for the purpose of achieving a common goal through verbal communication, such as sharing information or reaching an agreement. It may take the form of face-to-face or virtually, as mediated by communications technology, such as a telephone conference call, a Skype conference call or a video-conference olson1992small cutler2002distributed . When performing safety analysis, the meetings include planning meetings, review meetings and requirements audit/assessment meetings. The joined members are invited by a meeting organiser, such as a safety analysis moderator. The communication might produce work products as outputs, such as relevant documentation including safety plan or safety requirements implementation decisions.
Project coordination tool: 37 participants (94.9%) mentioned using project coordination tools as a main communication channel during safety analysis. Project coordination tools aim to increase group awareness of current tasks and issues and provide a means for tracking progress and discussing next steps storey2017social . Jira is the most popular one in our research context, together with the interfaces to other requirements management tools like Doors to keep the multiple levels and the traceability of safety requirements. Company A, company A1, company A2 and company A3 are using an Application Lifecycle Management (ALM) of IBM Rational Team Concert222https://arcadsoftware.de/produkte/rtc-rational-team-concert/. In daily work, employees can trace the progresses of safety analysis transparently and provide feedback or comments timely. In other communication channels, such as meetings or personal discussion, project coordination tools provide an up-to-date information, such as the implementation of a safety requirement.
Documentation: 36 participants (92.3%) mentioned documentation as a main communication channel during safety analysis. According to the functional safety standards, safety analysis requires a large amount of documentation, such as safety analysis instrumentations, safety analysis execution plans and safety analysis audit/assessment reports. To record processes and results of safety analysis clearly, the employees have to rely on these documents.
Telephone: 33 participants (84.6%) mentioned the use of the traditional telephone. Even though other modern communication software is springing up, most of the employees believe that telephone is more reliable for local communication and just as easy to use as in daily life baym2004social kiesler1992group . We obtained a novel channel calling a telephone call via Skype in our research context. Company A links the telephone numbers with the Skype accounts. It enhances the work efficiency. For example, when someone is on the way among different work places, he or she can keep the communication via various mobile terminals, such as mobile phone or tablet personal computer.
Email: 32 participants (82.1%) mentioned the use of email. As an asynchronous communication channel, when the issues are not emergent and might involve not only one person, email provides time to structure the information for communication dabbish2005understanding . Concerning safety analysis, email threads and the contents of emails are traceable. The traceability constitutes an advantage of using email. However, using email is not fully positive during safety analysis. Email can record the process of discussion, yet the practitioners during safety analysis do not prefer recording their discussion, rather only documenting their results. In addition, although using emails seems traceable, there needs a lot of efforts to search for the relevant information.
Personal discussion: 28 participants (71.8%) mentioned personal discussion as a communication channel during safety analysis. Personal discussion is a form of informal face-to-face communication. It happens spontaneously and less supported by communication technology kraut1990informal . When performing safety analysis, an internal communication prefers mostly using personal discussions. It can ensure a correct understanding and a timely feedback. To perform safety analysis in modern software development, personal discussion needs attentions and the effectiveness of it will influence the quality of safety analysis to a great extent.
Training (including tutorial): 19 participants (48.7%) mentioned training including tutorials as a communication channel. Training is a traditional way to enhance personal competence and share knowledge in industries saks2006investigation . In terms of safety analysis, the education institutes sometimes lack such courses, especially the practical experiences in developing safety-critical systems. A training of safety analysis or functional safety standards is a normal way to cultivate employees. However, some of the employees are already experts from other relevant positions or departments in industries, such as product development or quality assurance departments. They have already a deep experience. Thus, not all the participants have to take part in the training.
Internal communication software (private): 15 participants (38.5%) mentioned internal communication software as a communication channel. We consider only the internal communication software that features a private chat, since not all the software featuring group or public chats in our research context (company A uses Skype that supports public chat, while company A2 uses Microsoft Office Communicator (OCS) that does not support public chat). It is a relative new communication channel popularising in the last decade. It integrates functions like a real-time notification, documents transformation and even meeting organisation storey2010impact . Even though, the results indicate that internal communication software is not as much used during safety analysis as in other areas, such as software development storey2017social . We speculate that concerning each single function, the employees still have a better choice for achieving the purposes of safety analysis, such as for a real-time communication, telephone is more reliable to get in touch.
Boards: 6 participants (15.4%) mentioned the use of boards. Boards, as communication channels, have been popularly used in industries and are becoming a tool during project management, such as whiteboards cherubini2007let , in modern development processes. They are placed near the work areas. Some of them demonstrate the state-of-the-art or contributions in terms of safety analysis, such as a process flowchart of safety analysis in product development or the developed interfaces in safety analysis and relevant tools. In particular, when external experts or customers come to visit the company, boards are an intuitive way to show competitiveness.
5.2 RQ2: How frequently used are safety analysis communication channels?
Meetings are mostly held ranging from 1-4 times per week (18 out of 39 respondents, 46.2%) to 1-4 times per month (18 out of 39 respondents, 46.2%). Personal discussion happens 1-4 times per week (18 out of 27 respondents, 66.7% ). Internal communication software is used mostly 1-4 times per week (11 out of 15 respondents, 73.3%). Email (18 out of 32 respondents, 56.3%) and telephone (23 out of 33 respondents, 69.7%) are also frequently used 1-4 times per week. Documentation is written, read or managed 1-4 times per week (27 out of 36 respondents, 75%). Project coordination tools are in use 1-4 times per day (36 out of 37 respondents, 97.3%). Training is established 1-4 times per year with 100% respondents’ rate. Boards are possibly to be noticed 1-4 times per week (4 out of 6 respondents, 66.7%). In summary, most of the communication channels (7 out of 9) are in use for safety analysis at least every week. Project coordination tools are in use for safety analysis everyday, while training (including tutorial) concerning safety analysis is mostly held every year. In particular, the same number of participants (18 participants) mention that the meetings are held between 1-4 times per week and 1-4 times per month. We discuss this point with an expert in company A and consider the reason to be the distribution of the company. For local projects, it is possible to establish necessary meetings. However, the distributed projects occupy also a large percentage in our research context. It is almost impossible for the employees, who are in distributed locations, to find a common time slot, such as in Germany, China, and USA. In these cases, meetings cannot be so frequently held at a 1-4 times per week rate and other communication channels are in use instead.
5.3 RQ 3: Which are the purposes of safety analysis communication channels?
We address overall 28 purposes of 9 communication channels during safety analysis, as we can see in Table 3.
1. Transfer safety requirements (in). To transfer safety requirements internally, the employees use meetings, documentation and project coordination tools. They discuss safety requirements in the form of meetings to keep it formal and possible to be established among multiple functional departments. They record the safety requirements in official documentation and project coordination tools to support daily communication.
2. Transfer safety requirements (ex). To transfer safety requirements externally, meetings and documentation are implemented. However, contrary to the internal transfer of safety requirements, project coordination tools mostly have a limitation on permissions to external members. Some of the customers send the safety requirements per email, which seems to be non-regulated due to a lack of format of constructing safety requirements and an acceptance process of safety requirements.
3. Derive safety requirement. A formal and thorough discussion is necessary to derive correct and complete safety requirements. Thus, meeting is the most effective way with respect to the number of participants and time.
4. Clarify safety requirements internally. Many communication channels are applicable to clarify safety requirements internally, which include meetings, personal discussion, internal communication software (private), telephone, documentation and project coordination tools. It depends on the impact degree and scope of misunderstandings. A meeting is ideal for clarifying safety requirements with a severe impact. Personal discussion, internal communication software (private) and telephone are better for an individual clarification. Documentation is used to record an official clarification, while project coordination tools are specific for a clarification in an open mode.
5. Clarify safety requirement externally. An official and reliable communication channel is extremely important to clarify safety requirements externally. Thus, meetings and documentation are the most appropriate channels. Email has also been used for an explanation at an early stage.
6. Implement safety requirements. The developers should implement safety requirements to their development. In terms of accountability, they prefer to execute it through meetings and documentation. The generation of ideas may happen through personal discussion.
7. Trace safety requirements (bi). According to the standards, safety requirements should satisfy a bi-directional traceability iec61508 . Project coordination tools give the employees a direct overview. However, to preserve them long-term, documentation is needed. In addition, some project coordination tools do not support multiple level safety requirements, such as Jira.
8. Planning. To perform safety analysis planning, a planning meeting is a popular way, together with a safety plan as a work product. The execution process is shown in a project coordination tool.
9. Regular discussion. It includes regular meetings in the development team or personal discussion among team members. Sometimes the team members use internal communication software.
10. Demonstrate periodic analysis results. The safety analysis results should be demonstrated periodically to promote development. The results are transmitted automatically in the project coordination tools. The safety analysts demonstrate the results via the meeting and record them in the documentation.
11. Demonstrate periodic V&V results. It is the same way with purposes 10. The acceptance criteria for safety verification and validation are recorded in the documentation and the review process is running in a meeting with a record in the project coordination tools.
12. Review. There is a regular review meeting held at the end of a project. The results are recorded in the review report and in a project coordination tool at the same time.
13. Monitor the status. Some practitioners facilitate communication for monitoring the status of safety analysis. The project coordination tool is the best way for monitoring the status in terms of a convenience and completeness overview.
14. Fix resources/supply problems. Safety analysis sometimes faces the problems concerning a lack of resources or supply. The resources or suppliers are inside the company, yet among different subsidiaries or multiple functional departments. Meeting and personal discussion are the normal ways to fix such official but less frequent issues.
15. Fix customers’ complaints. The employees receive the customers’ complaints mostly through emails. Solving the problems is achieved through meetings.
16. Establish commitments and make decisions. The commitments are established among various roles, while the decisions are made in a formally strategic way. Meeting is the most suitable method.
17. Improve processes and techniques. The processes and techniques of safety analysis are continuously developed. No matter how subtle the changes are, these changes have to be considered and discussed systematically and transparently pino2008software . Meeting can gather omnifarious opinions and perform allocations from an overall perspective.
18. Fix temporary problems, conflicts and obstacles. There are many unforeseeable and even tiny problems, conflicts and obstacles during safety analysis, possible communication channels are meeting, personal discussion, internal communication software, email and telephone. The selection of the channels depends on concrete issues.
19. Cooperate among multiple functional departments. A meeting is possible to be organised across multiple functional departments. The employees might also communicate through personal discussion, when they have a good relationship privately. The employees are also using internal communication software, email and telephone to communication with multiple functional departments.
20. Help to understand the standards. The activities and artifacts of performing safety analysis have to satisfy the standards. Not everyone has a solid background. To understand the standards, safety managers might introduce briefly in a meeting. More than that, the employees could ask relevant experts through personal discussion. To this end, training is popular in safety-critical companies to illustrate the standards systematically.
21. Realise real-time notifications. Some issues related to safety analysis are emergent, such as a serious customers’ complaint, which might influence an ongoing delivery. In this case, the employees usually go directly to find the colleague (personal discussion), using internal communication software or telephone. Some project coordination tools provide a timely notification function in connection with email.
22. Provide feedback and comments. The employees are able to provide a timely feedback or comments through personal discussion, internal communication software, and telephone. Email is better for a clear explanation, while project coordination tools make the feedback and comments open to other employees.
23. Enhance group cohesion. Some communication channels among safety analysis and other stakeholders enhance safety-critical industries’ cohesion, such as internal communication software and project coordination tools. Training is especially useful for new employees.
24. Discuss off topics. The contents of off topics might influence the safety analysis positively or negatively. The employees mainly use internal communication software or directly personal discussion.
25. Share knowledge. Knowledge sharing is considered important in safety-critical systems nesheim2014knowledge , such as general safety knowledge or in-depth safety analysis information. It occurs through meeting, personal discussion, telephone, documentation, training and boards.
26. Transfer documents or links. The safety analysis related documents are mostly saved on a server. Yet, a small change of information management system as well as the complicated hierarchy of folders make some documents more difficult to be found or take more time than asking the responsible colleague. Thus, the employees might use communication channels to transfer them or their link. Internal communication software is a convenient way to share a link or an address, while email is able to send chunky files and keep track of the documents.
27. Enhance safety culture. Safety culture reflects the general attitude and approaches to safety and risk management leveson2011engineering . Safety culture is difficult to evaluate guldenmund2000nature . Documents are required by the standards. The satisfaction of such requirements of documents determines the organisation’s safety assurance capability. It influences the safety culture. Responsibilities of specific roles, such as safety manager, are important to meeting the standards. Thus, a training of standards is necessary for remaining a good safety culture. Some participants mentioned boards as a good way to enhance safety culture through daily work, such as hanging out recent contributions.
28. Demonstration (external). Boards are also popular to demonstrate the safety analysis capability of the organisations to external experts or customers. An intentional demonstration for a possible cooperation is conducted in meetings.
|Meeting||Personal discussion||Csw.||Tel.||Doc.||Project coordination tool||Training||Boards|
|1. Transfer safety requirements (in)||✓||✓||✓|
|2. Transfer safety requirements (ex)||✓||✓||✓|
|3. Derive safety requirements||✓|
|4. Clarify safety requirements (in)||✓||✓||✓||✓||✓||✓|
|5. Clarify safety requirements (ex)||✓||✓||✓|
|6. Implement safety requirements||✓||✓||✓|
|7. Trace safety requirements (bi)||✓||✓|
|9. Regular discussion||✓||✓||✓|
|10. Demonstrate periodic analysis results||✓||✓||✓|
|11. Demonstrate periodic V&V results||✓||✓||✓|
|13. Monitor the status||✓|
|14. Fix resources/supply problems||✓||✓|
|15. Fix customers’ complaints||✓||✓|
|16. Establish commitments and make decisions||✓|
|17. Improve processes or techniques||✓|
|18. Fix temp. problems, conflicts and obstacles||✓||✓||✓||✓||✓|
|19. Cooperate among multiple functional departments||✓||✓||✓||✓||✓|
|20. Help to understand the standards||✓||✓||✓|
|21. Realise real-time notifications||✓||✓||✓||✓|
|22. Provide feedback and comments||✓||✓||✓||✓||✓|
|23. Enhance group cohesion||✓||✓||✓|
|24. Discuss bordered or off topics||✓||✓|
|25. Share knowledge||✓||✓||✓||✓||✓||✓|
|26. Transfer documents or links||✓||✓|
|27. Enhance safety culture||✓||✓||✓|
|28. Demonstration (external)||✓||✓|
Csw. is internal communication software. Tel. is telephone. Doc. is documentation. V&V is verification and validation. In means internal, while ex means external. Bi means bi-direction.
5.4 RQ4: Which are the challenges when using safety analysis communication channels?
5.4.1 The Top 10 Challenges
We derive the top 10 challenges across 9 communication channels from interviews and check the results by a safety expert in company A. We list them as follows.
1. The communication of sensitive or confidential information should be monitored.
The results of safety analysis are mostly sensitive and confidential, since they encompass products in details, which influence a safe operation and end-use of products. Communication channels have to keep the information confidential, which includes ensuring that sensitive and confidential information is properly stored, maintained, secured, and accessible to those who need it banerjee2012ensuring lucey2004management . One interviewee mentioned: “We categorised the data (information) related to safety analysis with different confidentiality levels. Higher confidential data (information) requires relevant authorities to read and transmit. Yet, we do not regulate the verbal communication, including using social communication software to discuss the information. These information is not under monitor and control." We note one factor concerning initiative leakage (a lack of regulations) of sensitive or confidential information through communication channels rather than passive leakage (a poor security and privacy assurance mechanism). As one participant mentioned: “We always avoid some non-regulated channels to transmit confidential and sensitive data (information), such as using e-mail to send safety requirements, even though some customers do this. We actually do not know clearly what is such regulations, just following our experiences." To face this factor, organisation should establish relevant regulations on the communication channels, especially on the verbal channels, when performing safety analysis. The employees can understand clearly which sensitive and confidential information is able to transmit by which communication channels. Moreover, an alternative to verbal communication is recommended when performing safety analysis, such as text transmission.
2. Some safety analysis information is fragmented.
The fragmentation will cause misunderstandings on safety analysis information. This happens particularly in text-based communication channels, such as safety analysis related-documentation and internal communication software. As one interviewee mentioned: “Mostly we can find out the safety-analysis relevant documents on the server. But sometimes the information is difficult to be understood or also possibly lacking some critical information, maybe not updated. The files are uploaded by authors themselves with no more reviews and even regular maintenance." There is a specific role responsible for technical documents’ maintenance in industries. However, the maintenance for online documents seems weak. Moreover, for the synchronous communication channels like internal communication software. One interviewee said: “To save time, there are too many personal abbreviations. That makes us confused and influences some emergent issues."
3. Some safety analysis information is inconsistent.
The tools such as project coordinate tools and safety analysis tools are updated frequently. However, other recordings do not keep the same space. As one interviewee mentioned: “In Jira and Doors, which we are using for recording safety requirements, there are all the updated safety requirements. But sometimes we use also doc files to record the results from safety analysis firstly and do not use those directly. The update (of official requirements documents) has a determined time point, which is not in a timely manner." A real-time consistency seems important for the set of safety analysis related tools. In this paragraph, we focus on the contents, while the forth challenge focuses on the trigger time.
4. Some communication channels concerning safety analysis are asynchronous, when they should be synchronous.
Some communication channels are considered to be synchronous, such as Skype or telephone. However, they are not in our case. One interviewee mentioned: “When there is a temporary meeting, I will check if this colleague is online (Skype), then call him (or her). It works mostly. But once, I got an emergent customer complaint regarding our safety analysis, we need to find a colleague immediately, he was not online and could not be reached by telephone. I decided to go directly to his office and found him." The asynchronous channels will hinder some emergent issues such as production and delivery and might cause fatalities.
5. The communication channels concerning safety analysis lack tool support.
Tools often put a limit to the strategies that can be adopted leveson2011engineering . For effective communications, tools are important, especially the interfaces among different tools. When performing safety analysis, non-verbal communication takes an increasingly major part of it. An effective tool chain ensures the information’s correctness, clearness, completeness and synchronous. However, the integration between safety analysis and functional development still lacks tool supports. Various organisational structures have various communication channels and tools. The new techniques are changing too fast to arrange an immediately effective use of them. As one interviewee said: “We start to use ALM (from IBM) for project management, but the interfaces (with the existing management tools) are not finished. The traceability is too poor." The company has to consider an immediately developed interface with other safety analysis tools, when they introduce a new project management tool. Otherwise, when buying a new tool, a feasible interface to the existing toolchain should be considered by the compnay. As one interviewee mentioned: “APIS IQ-FMEA is a powerful tool that we used for performing FMEA. We have used it for many years and believe in it. Currently, we are considering to use a safety information and activity management tool. A lot of companies have introduced their tools. But our first criteria is if it has a feasible interface with APIS IQ-FMEA."
6. Developers might misunderstand the information from safety experts.
When the products to be developed have novel functions, there will be misunderstandings between functional developers and safety experts. One interviewee said: “It is no problem when developing old functions like ECU (electronic control unit). But these years we are starting a new functional module NCU (new energy control unit). The traditional safety experts, who have functional development experiences only on developing ECU, lack the new knowledge to understand detailed development." The communication channels which support knowledge sharing might be helpful in this case.
7. There are language, geographic and culture barriers in the communication channels.
In terms of language, most of the companies in our context use English as the official language. Nevertheless, some professional terms concerning safety analysis are not uniform, such as incorrect verbs like operate safety analysis instead of perform safety analysis. This happens in the text-based as well as verbal communication channels. In terms of geographic, distributed locations interfere experience sharing. As one interviewee mentioned: “We send our colleagues, who perform safety analysis to other countries once a year to enhance communication and collaboration, but it works better for new employees. They want to learn new techniques and former experiences. For safety experts, we prefer that the execution of safety analysis should be suitable for our own environment or context. Different countries have different requirements and problems." The basic knowledge has been well transmitted. However, the practical experiences are less shared and worse discussed. The knowledge sharing of safety analysis should not stop in the technique level, rather with more real-life cases. In terms of culture, distributed companies keep detailed safety analysis results and avoid to communicate them. There is a lack of trust among different cultures holmstrom2006global . The parent company keeps some details, such as architecture design, of development and even safety analysis. When the subsidiaries inherit some function modules, they lack such details to perform a thorough and systematic safety analysis. Regulations among different countries might be a reason.
8. The members from functional departments are unwilling to share safety knowledge with non-functional departments.
Functional (including functional safety) departments believe in their knowledge on development and safety of products. As one expert from the functional department said: “We don’t see the necessity to do this." We call this stereotype in groupthink theory333Groupthink is a psychological phenomenon, which was introduced by Janis in 1971 janis1971groupthink . It is a linear model of how seven antecedents (cohesion, group insulation, impartial leader, lack of norms, homogeneous, high stress from external threats, temporarily low self-esteem) increase the likelihood of premature concurrence seeking, which leads to eight psychological symptoms (illusion of invulnerability, collective rationalisations, belief in inherent morality of the group, stereotypes of out-groups, direct pressure on dissenters, self-censorship, illusion of unanimity, self-appointed mindguards).. This challenge exists during safety analysis and is specifically important for developing and ensuring a safe product wangw2018 . An interviewee said: “We do not think that other departments like purchasing or sales could help us a lot on developing a safe product. We know more and detailed on the product. For one project, we were required to train them with some general safety knowledge. We do not know how much it works. They also look unwilling." In terms of safety knowledge sharing, the functional departments (including functional safety) should appreciate the needs and expectation of other job roles. In addition, a lack of continuous learning and personal development processes reduce the passions of non-functional departments’ employees to learn safety-analysis related knowledge, as one interviewee mentioned: “Safety analysis is not my main job, if just for this project and it does not help for future, we actually do not want to use too much time on it." To this end, we should notice if the information is spread widely enough. As one expert said: “Sometimes the employees are forced to share the safety knowledge." A lack of initiative makes the knowledge sharing becoming superficial.
9. The storage, authority, regulation and monitoring problems on the transmitted safety analysis information.
In terms of the storage of safety analysis information, one interviewee mentioned: “We have a central information management system on the server, but the safety analysis data (information) or files are not clearly classified. Some (of them) are mixed with other process documents." The quality of transmitted information interleaves with the effectiveness of communication channels. The company should consider to establish a safety information management system to be separated with other information. In addition, the tools of information storage are important. An expert said: “The process of our data (information) storage is following the tools, not using tools to support process." Thus, a suitable tool for safety information storage is needed, especially for modern safety-critical systems with a huge amount of data. As one interviewee mentioned: “The simulation data for autonomous driving system are thousands of giga bytes. It is relative difficult to find them when there is a migration happened 10 years before." In terms of authority, one interviewee said: “In the information management system, we classify the files into different levels of authorities. But it is difficult to divide levels of safety requirements in Jira." The authority should be noticed not only in the information management system, but also in the project management tool. In terms of regulation, some feedback are: “We are not clear about the regulations, just big sizes of files cannot be sent privately." We notice that there are some hidden regulations on transmitting safety sensitive information. However, these regulations are not clearly and obviously announced. In terms of monitoring problems, the safety analysis information are monitored by an IT department as the same with other company level sensitive information. As one interviewee mentioned: “We do have a monitor group that monitors and controls the transformation of marked files. The high severity files have different kinds of mark. It could be traced by IT department." The monitor of safety analysis information does work inside the company, but still needs enhancement.
10. There is a lack of technical documentation to support communication.
Safety analysis should be performed at the system level leveson2011engineering . The detailed system description documents are necessary but sometimes not available. One interviewee mentioned: “Some products are developed on the basis of the original product. The functions are inherited. The detailed architecture design documents are kept by the original company or department. The execution of safety analysis cannot only be performed on new function modules without considering interfaces with original products. A systematic impact causes risks." This might be caused by the culture (as we indicate in challenge 7), the authority problem (as we mentioned in challenge 9) of subsidiaries, or an incomplete and fragment record of safety analysis information (as we mention in challenge 2). Nevertheless, safety analysis related documentation should consider communication wang2017study .
5.4.2 A Mapping between Purposes and Challenges
|Purposes vs. Challenges||1||2||3||4||5||6||7||8||9||10|
|1. Transfer safety requirements (in)||✓||✓|
|2. Transfer safety requirements (ex)||✓||✓|
|3. Derive safety requirements||✓||✓||✓|
|4. Clarify safety requirements (in)||✓||✓|
|5. Clarify safety requirements (ex)||✓||✓||✓|
|6. Implement safety requirements||✓||✓|
|7. Trace safety requirements (bi)||✓|
|9. Regular discussion||✓|
|10. Demonstrate periodic analysis results||✓||✓|
|11. Demonstrate periodic V&V results||✓||✓|
|13. Monitor the status||✓||✓|
|14. Fix resources / supply problems||✓|
|15. Fix customers’ complaints||✓||✓|
|16. Establish commitments and make decisions||✓||✓|
|17. Improve processes or techniques||✓|
|18. Fix temp. problems, conflicts and obstacles||✓|
|19. Cooperate among multiple functional departments||✓||✓|
|20. Help to understand the standards||✓||✓|
|21. Realise real-time notification||✓|
|22. Provide feedback and comments||✓||✓|
|23. Enhance group cohesion||✓|
|24. Discuss boards line or off topics||✓|
|25. Share knowledge||✓||✓|
|26. Transfer documents or links||✓||✓|
|27. Enhance safety culture||✓|
|28. Demonstration (external)||✓|
In. csw (private) is internal communication software. Tel. is telephone. Doc. is documentation. V&V is verification and validation. In means internal, while ex means external.
We map the purposes with challenges, as shown in Table 4. The first line depicts the numbers of the top 10 challenges, while the first column depicts the purposes.
Considering challenge 1: The communication of sensitive or confidential information should be monitored. It happens often when the practitioners transfer and demonstrate safety analysis related information (purpose 1, 2, 24, 26, 28). The practitioners, who use the communication channels for achieving these purposes, should notice challenge 1. Other communication channels are better to avoid transferring sensitive or confidential information.
Considering challenge 2: Some safety analysis information is fragmented. The incomplete and fragment information occur through almost all the 9 communication channels, especially for demonstrating information (purpose 10, 11). Documentation, project coordination tools, email and internal communication software should keep safety analysis related information as complete as possible. When facing resource or supply problems, the provided information from them should notice completeness (purpose 14).
Considering challenge 3: Some safety analysis information is inconsistent. When the practitioners clarify the safety requirements (purpose 3, 4, 5) or demonstrate the results (purpose 10, 11), the communication channels should keep consistent information to avoid misunderstandings. Thus, the consistency among the recordings of meetings, the archived documentation and the project coordination tools seem important.
Considering challenge 4: Some communication channels concerning safety analysis are asynchronous, when they should be synchronous. It is extremely important when there is a need for real-time notification and timely monitoring (purpose 13, 15, 22). Thus, telephone, internal communication software should be able to reach a specific person when he/she is on-site.
Considering challenge 5: The communication channels concerning safety analysis lack tool support. A tool is necessary for tracing safety requirements (purpose 7), monitoring status (purpose 13) and providing feedback (purpose 22). The temporary problems necessitate tools to support recordings (purpose 18). We should arrange or design efficient tools and their interfaces as well.
Considering challenge 6: Developers might misunderstand the information from safety experts. The misunderstanding might occur between developers and safety experts when they use communication channels internally to derive, clarify, implement, discuss, review and share the safety analysis related information (purpose 3, 4, 6, 9, 12, 25). The understanding with respect to standards show also bias (purpose 20). The practitioners need to consider the understandability and an obstacle-free communication among multiple functional departments.
Considering challenge 7: There are geographic, language and culture barriers in the communication channels. When the industries aim to enhance group cohesion and share safety knowledge (purpose 24, 26), the communication channels, such as internal communication software, training and boards, might reduce the interferences from geographic, language and culture bias. To face customers or clarify safety analysis externally, it might happen in a multiple geographical distribution (purpose 5, 15). The relevant communication channels, such as meeting, should consider it.
Considering challenge 8: The members from functional departments are unwilling to share safety knowledge with non-functional departments. The communication channels regarding the cooperation among multiple functional departments (purpose 20) should avoid this challenge. For example, during meetings, a friendly environment for discussion is necessary. Personal discussion, such as by using internal communication software, email and telephone, is encouraged among multiple functional departments. When clarifying safety requirements externally (purpose 5), this challenge may happen due to a diverse knowledge background. When planning safety analysis (purpose 8), non-functional departments are keeping silence, as well as when improving processes or techniques (purpose 17). To enhance safety culture (purpose 27), non-functional departments should be included.
Considering challenge 9: The storage, authority, regulation and monitoring problems on the transmitted safety analysis information. To transfer safety requirements (purpose 1, 2, 26), storage, authority, regulation and monitoring are necessary. To establish commitment and make decisions (purpose 16), relevant regulations are needed. The fulfillment of standards should follow regulations (purpose 20). The feedback and comments need to be stored (purpose 22).
Considering challenge 10: There is a lack of technical documentation to support communication. The derive, implementation and decision making of safety requirements need a clear documentation to be understood by multiple functional departments and support an effective communication among them (purpose 3, 6, 16, 19).
The main benefit of our article is that we investigate the general topic concerning communication channels in a concrete context concerning the execution of safety analysis. We aim to arouse the awareness of practitioners concerning safety analysis on their communication. The results are multiple: (1) we find 9 communication channels during safety analysis; (2) most of them happen 1-4 times per week; (3) we investigate 28 purposes of these 9 communication channels and (4) the top 10 challenges across these 9 communication channels.
To compare with the related works, Storey et al. storey2017social found around twenty communication channels during software development. When performing safety analysis, the number of communication channels are smaller. We conjecture that (1) safety analysis is an activity within software development, (2) the confidentiality concerning sensitive safety-related data limit the number of possible communication channels, especially informal communication channels. Kraut et al. kraut1990informal mentioned that the usage frequency can show the importance of communication. In this article, we calculate the usage frequencies of the 9 communication channels during safety analysis to raise the importance of communication during safety analysis. Vilela et al. vilela2017integration proposed more than 11 pros that an effective communication in safety analysis can bring, such as reducing errors in requirements specification or helping design. However, to achieve an effective communication, the realisation of communication purposes is first and foremost. The existing research concerning communication purposes seem poor. We conjecture the reason might be that the general communication purposes distribute too wide-ranging. However, during safety analysis, the communication purposes can be accounted. The challenges of communication concerning safety issues were mentioned in plenty of studies, which are either accident reports lrsc or in terms of general organisation management hummel2013role . The summarised communication challenges in software development are more than twenty storey2017social . However, to the best of our knowledge, few research focus on the communication challenges, which might cause unsafe issues, during the execution of safety analysis in organisation management.
“Being a good communicator is one thing. Knowing what to communicate is much more important." conboy2011people (P. 52, Conboy et al.)
To see the results in this article, given the aforementioned opinion, we highlight the major contribution of our results as communication purposes (RQ 3). During our research, a lot of the popular communication channels are used across various areas, not only for safety analysis. The challenges are summarised with similar manifestations, such as incomplete information and asynchronous implementation, but they are totally different in essence in terms of causalities, effects as well as solutions. Some of the challenges cannot map into safety analysis directly. We believe that a purpose during the communication in safety analysis determines why and what to communicate. Communication makes sense when the people achieve their communication purpose.
Thus, in this article, first, we map the 9 communication channels (RQ 1) with the 28 purposes. Within these 28 purposes, each one has 1 to 6 possible selections of communication channels to achieve it. For instance, to derive safety requirements (purpose 3), to establish commitments and make decisions (purpose 16) and to improve processes and techniques (purpose 17), the practitioners show only the use of meetings. To clarify safety requirements internally (purpose 4) and to share knowledge (purpose 25), each purpose has 6 communication channels as possible selections in practice. Second, we map the top 10 challenges (RQ 4) with their 28 purposes. The challenges rely heavily on their purposes and have different manifestations on each channel. For instance, “the communication of sensitive and confidential information should be monitored" (challenge 1) when “transfer safety requirements" (purpose 1, 2), as shown in Table 4, rather than whether the practitioners use meetings, email, documentation or project coordination tools, as shown in Table 3.
In addition to the major contribution on communication purposes, we demonstrate firstly the state-of-the-art in terms of the types (RQ 1) of the existing communication channels. The number is not huge comparing with existing communication channels in other areas such as social media storey2010impact .
Meeting is a dominant one during safety analysis, which is able to achieve 20 out of 28 purposes. Especially, three purposes (3, 16, 17) can only be reached by meetings. The practitioners prefer to use meetings in traditional development processes which advocate formality as well as in modern development processes which aim to increase cooperation and communication. Meetings are possible for them both.
Project coordination tool, documentation, telephone and email are four popular communication channels in organisation management, as well as when performing safety analysis. They are able to reach 11 purposes, 12 purposes, 6 purposes and 7 purposes in safety analysis, respectively.
The importance of personal discussion is an outstanding result in our study. 71.8% participants mentioned that they are using it during safety analysis. It can achieve 11 out of 28 purposes. Based on our original conjecture, personal discussion might happen occasionally and especially rarely during safety analysis. Safety analysis is considered to be a technically in-depth activity, which needs an official communication or at least, more time to prepare. Comparing with other 8 communication channels, personal discussion seems to be the most unregulated one, which is extremely difficult to control, monitor and trace. We missed noticing its necessity. Yet, the results caught our attention.
Internal communication software is a novel channel since last decade. Even though it has been moderately mentioned in our context, the results show still its powerful functionalities that it can reach 9 purposes during safety analysis.
Training is a concentrated way to enhance communication concerning safety analysis. It can reach 4 purposes. Apart from the basic training for new employees, some specific training programs, or even expert-level training, should be arranged.
Boards are familiar for industries. It can achieve 3 purposes. Due to the modern development processes, such as whiteboards cherubini2007let from Kanban, the practitioners could consider extending the boards’ functionalities, particularly during safety analysis.
To strength the existing communication channels further, the usage frequencies (RQ 2) in practice can demonstrate their importances. We set 4 scales including 1-4 times per day, 1-4 times, per week, 1-4 times per month and 1-4 times per year. Generally, 7 out of 9 communication channels are used 1-4 times per week. Project coordination tools are used 1-4 times per day. We discussed it with a safety expert and he said: “To start an (safety analysis) activity, we check the state as the first step, because we just switched from other tasks. Project coordination tool (Jira) is convenient, complete and intuitive." A general overview is necessary before facilitating an issue. The project coordination tool is easy to use and it provides almost all the information or ways to get these information in a project. Training concerning safety analysis happens 1-4 times per year. From our viewpoint, it is reasonable.
As an initial step to investigate communication channels during safety analysis, we concentrate on the top 10 challenges (RQ 4) based on analysing our qualitative data and a final check by an expert in company A. Several of them show similar problems as in general communication channels, such as incomplete and fragmented information. Yet, during safety analysis, we notice that the fragmentation of information are in high severities and may cause fatalities. The completeness is not dominant. As one expert mentioned: “ 90% (incomplete) information sometimes is fully sufficient for solving the problems during safety analysis. But when the information is complete but fragmented, such as safety cases, which are spread over different tools, that seems serious." Geographical problems are also popular in general communication channels. Developers cannot get in touch to exchange states. However, during safety analysis, it influences not only the information transmission, but also safety knowledge sharing. These challenges need separate considerations. Other challenges are specifically existing in the communication channels during safety analysis, such as confidentiality concerning safety analysis information and groupthink including unwillingness to share safety analysis information with non-technical members.
For theory, RQ 1, RQ 2 and RQ 3 might provide implications, since as far as we know, there are no reported results on the existing communication channels as well as their usage frequencies and purposes during safety analysis. The communication in safety-critical industries should arouse attentions. We believe that in developing safety-critical systems, the practitioners are not keen on enriching the amount of channels, rather, solving the challenges on the existing communication channels to ensure a safe development process and a safe product. Thus, the 9 communication channels during safety analysis are convincing. Most of the communication channels are frequently used per week. In addition, RQ 3 provides 28 purposes of communication during safety analysis. In the future, we expect that researchers could expand this study to more safety-critical companies, domains and countries to check and enrich our initial results on the number of communication channels, their usage frequencies and purposes. Depending on the sizes of companies, there might be various answers.
For practitioners, RQ 4 might arouse more interest. Practitioners in safety-critical industries may have these problems in their running projects. However, we do not provide any solutions to each specific challenge in this article, since we believe that the contexts and tools of each communication channel are changing, the challenges may remain challenges in the future but with different manifestations. The solutions should be derived in a specific way. Moreover, the mappings between RQ 1 and RQ 3 as well as between RQ 3 and RQ 4 seem practically useful. For achieving the communication purposes during safety analysis, the practitioners can select the possible channels from Table 3 and know the possibly relevant challenges from Table 4. In the future, we expect that the practitioners could propose more challenges that they have met as well as solutions, either in a general way or specifically in a context.
We believe that three major limitations threaten the results of our study.
Our sample might not cover all possible roles during safety analysis; the results could be biased by an over-representation of medium sized companies, and we could not cover all possible domains where safety analysis is critical (e.g., aerospace). Finally, the sample could cover only companies from three countries. We believe, however, that the sample is rich and meets a high standard for qualitative case studies. Our sample of 60 participants covers all possible company sizes (small, medium, and large), offers data from two geographically and culturally diverse zones (Germany/Italy and China), and considers three different domains of interest (automotive, medical, and industry 4.0). For a stronger generalization of our results, we call for survey studies between companies to go wide where we could go deep within companies.
Communication occurs frequently and often spontaneously, so it is challenging to observe it directly. In our case study, while we could perform direct observation sessions, we mostly collected perceptions and experiences of participants. Memory recalling and other cognitive biases could over or under-represent certain communication channels and their usage frequency. This is a typical issue of observation studies, questionnaires, and interview-based designs Creswell2009 that we wish to recall nonetheless.
Furthermore, causality chains (e.g., those in RQ 3 and RQ 4) are harder to empirically demonstrate as there was no controlled experiment testing the claims. There is an open debate on whether causality can be inferred from research approaches other than controlled experiments Creswell2009 ; Djamba:2002jo ; Glaser:2013ha . We agree with several authors, e.g., Gläser et al. Glaser:2013ha , take the stance that qualitative data analysis can be used to infer causality from the experience of participants, provided that there is a strong methodology for data gathering and analysis. We claim that our methodology is robust. We have employed data triangulation validation whenever possible, for example by adding a three weeks long direct observation to validate the results and by offering our results to a senior functional safety expert from company A to check. Still, given the lack of prior literature, we deem our study to be exploratory in its nature, not confirmatory. We call for future research to empirically demonstrate the relationship chains that we uncovered.
7 Conclusion and Future Work
To investigate the communication channels during safety analysis, we conducted an industrial exploratory case study in 7 safety-critical industries with overall 60 participants. We used surveys, interviews, documentation review and participant observation in a large automotive company (with three medium subsidiaries), a large medical equipment company, a medium automotive company and a small industrial 4.0 based production line company. During three rounds of data collection, we found 9 communication channels during safety analysis. Most of them happen 1-4 times per week. We summarised 28 purposes of these 9 communication channels and the top 10 challenges across these 9 communication channels. We notice the importance of communication purposes and map them with the existing channels and challenges. Our study is mainly limited by the domains, participants’ background and countries, which cover only 3 safety-critical domains and mainly in Europe and Asia with only 60 participants.
Further research could expand our study and enrich our preliminary results, such as with more subjects to generate communication channels between different senders and receivers, in more safety-critical domains like aviation or railway industries. In addition, a quantitative assessment for these challenges and some practical solutions are expected to be generated.
We would like to thank all the participating companies as well as colleagues helping out in different parts of this research, especially Yun Jiang, Liqiang Dong, Jakubasch Ronny, Schmidt Klaus, Michael Fijala, Roberto Secchi and Suneet Jain, as well as their help to our previous research on groupthink in safety analysis wangw2018 .
Yang Wang has been supported by LGFG Fellowship (Promotionsstipendien nach dem Landesgraduiertenförderungsgesetz, Baden-Württemberg). Daniel Graziotin has been supported by the Alexander von Humboldt (AvH) Foundation.
- (1) L. E. Martins, T. Gorschek, Requirements engineering for safety-critical systems: Overview and challenges, IEEE Software 34 (99) (2017) 49–57.
- (2) N. Leveson, Engineering a safer world: Systems thinking applied to safety, MIT Press, Cambridge, MA, 2011.
- (3) I. O. for Standardisation, ISO 26262: Functional safety of electrical and/or electronic systems in production automobiles, International Organisation for Standardisation, 2011.
- (4) T. Reiman, P. Oedewald, Evaluating safety-critical organisations - Emphasis on the nuclear industry, Finland VTT.
- (5) L. Rierson, Developing safety-critical software: A practical guide for aviation software and DO-178C compliance, CRC Press, Boca Raton, Florida, 2017.
- (6) J. Vilela, J. Castro, L. E. G. Martins, T. Gorschek, Integration between requirements engineering and safety analysis: A systematic literature review, Journal of Systems and Software 125 (2017) 68–92.
- (7) M. Hummel, C. Rosenkranz, R. Holten, The role of communication in agile systems development, Business & Information Systems Engineering 5 (5) (2013) 343–355.
- (8) J. Keyton, Communication in organisations, Annual Review of Organisational Psychology and Organisational Behaviour.
- (9) R. E. Kraut, R. S. Fish, R. W. Root, B. L. Chalfonte, Informal communication in organisations: Form, function, and technology, in: Human Reactions to Technology: Claremont Symposium on Applied Social Psychology, 1990, pp. 145–199.
- (10) T. Reiman, C. Rollenhagen, E. Pietikäinen, J. Heikkilä, Principles of adaptive management in complex safety-critical organisations, Safety Science 71 (2015) 80–92.
- (11) K. Dobson, A. Moors, B. Norris, Literature review of safety critical communication methodologies, ERA 2014 INTEROP OP.
- (12) J. D. Johnson, W. A. Donohue, C. K. Atkin, S. Johnson, Differences between formal and informal communication channels, The Journal of Business Communication 31 (2) (1994) 111–122.
- (13) J. Bowen, V. Stavridou, Safety-critical systems, formal methods and standards, Software Engineering Journal 8 (4) (1993) 189–209.
- (14) M.-A. Storey, A. Zagalsky, F. Figueira Filho, L. Singer, D. M. German, How social and communication channels shape and challenge a participatory culture in software development, IEEE Transactions on Software Engineering 43 (2) (2017) 185–204.
- (15) A. Cockburn, Agile software development, Addison-Wesley Boston, 2002.
- (16) J. Whitehead, Collaboration in software engineering: A roadmap, in: Future of Software Engineering, 2007, pp. 214–225.
- (17) A. Alliance, Agile manifesto, Online at http://www. agilemanifesto. org 6 (1).
- (18) L. Williams, R. Kessler, Pair programming illuminated, Addison-Wesley, Boston, 2002.
- (19) K. Schwaber, M. Beedle, Agile software development with Scrum, Vol. 1, Prentice Hall, Upper Saddle River, New Jersey, 2002.
- (20) Y. Lindsjørn, D. I. Sjøberg, T. Dingsøyr, G. R. Bergersen, T. Dybå, Teamwork quality and project success in software development: A survey of agile development teams, Journal of Systems and Software 122 (2016) 274–286.
- (21) M. Pikkarainen, J. Haikara, O. Salo, P. Abrahamsson, J. Still, The impact of agile practices on communication in software development, Empirical Software Engineering 13 (3) (2008) 303–337.
- (22) A. Martini, L. Pareto, J. Bosch, A multiple case study on the inter-group interaction speed in large, embedded software companies employing agile, Journal of Software: Evolution and Process 28 (1) (2016) 4–26.
- (23) M. L. Drury-Grogan, K. Conboy, T. Acton, Examining decision characteristics & challenges for agile software development, Journal of Systems and Software 131 (2017) 248–265.
- (24) T. Stålhane, T. Myklebust, G. Hanssen, The application of Safe Scrum to IEC 61508 certifiable software, in: Proceedings of the 11th International Probabilistic Safety Assessment and Management Conference and the Annual European Safety and Reliability Conference, 2012, pp. 6052–6061.
- (25) S. Prineas, Safety-critical communication, Handbook of communication in anaesthesia & critical care: A practical guide to exploring the art (2010) 189.
- (26) R. H. Flin, P. O’Connor, M. Crichton, Safety at the sharp end: A guide to non-technical skills, Ashgate Publishing, Farnham, 2008.
- (27) W. H. Gibson, Literature review of safety related communication, Report for Railtrack PLC.
- (28) P. Runeson, M. Host, A. Rainer, B. Regnell, Case study research in software engineering: Guidelines and examples, John Wiley & Sons, Hoboken, New Jersey, 2012.
- (29) A. Strauss, J. Corbin, Grounded theory methodology, Handbook of Qualitative Research 17 (1994) 273–285.
- (30) G. M. Olson, J. S. Olson, M. R. Carter, M. Storrosten, Small group design meetings: An analysis of collaboration, Human Computer Interaction 7 (4) (1992) 347–374.
- (31) R. Cutler, Y. Rui, A. Gupta, J. J. Cadiz, I. Tashev, L. He, A. Colburn, Z. Zhang, Z. Liu, S. Silverberg, Distributed meetings: A meeting capture and broadcasting system, in: Proceedings of the 10th ACM International Conference on Multimedia, 2002, pp. 503–512.
- (32) N. K. Baym, Y. B. Zhang, M.-C. Lin, Social interactions across media: Interpersonal communication on the internet, telephone and face-to-face, New Media & Society 6 (3) (2004) 299–318.
- (33) S. Kiesler, L. Sproull, Group decision making and communication technology, Organisational Behaviour and Human Decision Processes 52 (1) (1992) 96–123.
- (34) L. A. Dabbish, R. E. Kraut, S. Fussell, S. Kiesler, Understanding email use: Predicting action on a message, in: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2005, pp. 691–700.
- (35) A. M. Saks, M. Belcourt, An investigation of training activities and transfer of training in organisations, Human Resource Management 45 (4) (2006) 629–648.
- (36) M.-A. Storey, C. Treude, A. van Deursen, L.-T. Cheng, The impact of social media on software engineering practices and tools, in: Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research, 2010, pp. 359–364.
- (37) M. Cherubini, G. Venolia, R. DeLine, A. J. Ko, Let’s go to the whiteboard: How and why software developers use drawings, in: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2007, pp. 557–566.
- (38) I. E. Commission, IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems, International Electrotechnical Commission, 2011.
- (39) F. J. Pino, F. García, M. Piattini, Software process improvement in small and medium software enterprises: A systematic review, Software Quality Journal 16 (2) (2008) 237–261.
- (40) T. Nesheim, L. J. Gressgård, Knowledge sharing in a complex organisation: Antecedents and safety effects, Safety Science 62 (2014) 28–36.
- (41) F. W. Guldenmund, The nature of safety culture: A review of theory and research, Safety Science 34 (1-3) (2000) 215–257.
- (42) A. Banerjee, K. K. Venkatasubramanian, T. Mukherjee, S. K. S. Gupta, Ensuring safety, security, and sustainability of mission-critical cyber-physical systems, Proceedings of the IEEE 100 (1) (2012) 283–299.
- (43) T. Lucey, Management information systems, Cengage Learning EMEA, 2004.
- (44) H. Holmstrom, E. Ó. Conchúir, J. Agerfalk, B. Fitzgerald, Global software development challenges: A case study on temporal, geographical and socio-cultural distance, in: Proceedings of the International Conference on Global Software Engineering, 2006, pp. 3–11.
- (45) I. L. Janis, Groupthink, Psychology Today 5 (6) (1971) 43–46.
- (46) Y. Wang, S. Wagner, On groupthink in safety analysis: An industrial case study, in: Proceedings of the 40th International Conference on Software Engineering, 2018.
- (47) Y. Wang, I. Bogicevic, S. Wagner, A study of safety documentation in a scrum development process, in: Proceedings of the XP 2017 Scientific Workshops, 2017, p. 22.
- (48) K. Conboy, S. Coyle, X. Wang, M. Pikkarainen, People over process: Key challenges in agile development, IEEE Software 28.
- (49) J. W. Creswell, Research design: Qualitative, quantitative, and mixed method approaches, 3rd Edition, Vol. 2, Sage Publications, Thousand Oaks, California, Thousand Oaks, California, 2009.
- (50) Y. K. Djamba, W. L. Neuman, Social research methods: Qualitative and quantitative approaches, Teaching Sociology 30 (3) (2002) 380.
- (51) J. Gläser, G. Laudel, Life with and without coding: Two methods for early-stage data analysis in qualitative research aiming at causal explanations, Forum: Qualitative Social Research.