مشخصات مقاله انگلیسی (PDF)
سال انتشار مقاله	2003
تعداد صفحات مقاله انگلیسی	17 صفحه با فرمت pdf
رشته های مرتبط با این مقاله	مهندسی صنایع و مدیریت صنعتی
گرایش های مرتبط با این مقاله	برنامه‌ریزی و تحلیل سیستم‌ها، تولید صنعتی، تکنولوژی صنعتی، ایمنی صنعتی، بهینه سازی سیستم ها، تولید وعملیات و مدیریت عملکرد
مجله مربوطه	علوم کامپیوتر (Computer Science)
کلمات کلیدی این مقاله	ارزیابی ایمنی و رسمی سیستم های پیچیده، رایانش خودکار درخت خطا، ESA CS
شناسه شاپا یا ISSN	ISSN 0302-9743
لینک مقاله در سایت مرجع	لینک این مقاله در سایت Springer
نشریه اسپرینگر

• فهرست مطالب:

 ۱ مقدمه
۲ روش ESACS و پلت فرم ESACS
۲ ۱ روش ESACS
۲ ۲ پلتفرم ESACS
۳ مطالعه موردی: سیستم قدرت ثانویه
۴ نتایج
۵ کار های مشابه
۶ نتیجه گیری و کار های آینده

• بخشی از ترجمه:

در این مقاله ما از پلتفرم و روش  آنالیز ایمنی ESACS استفاده کردیم. پلتفرم ESACS را می توان به عنوان ابزاری برای   کمک به فرایند آنالیز ایمنی از مراحل اولیه طراحی سیستم برای مراحل ارزیابی ایمنی و صحت سنجی استفاده می شود. هدف اصلی ایجاد محیطی است که بتواند توسط  هر دو مهندسان طراحی  برای تایید رسمی سیستم و مهندسان ایمنی  برای  اتوماسیون مراحل ویژه ارزیابی های ایمنی مورد استفاده قرار گیرد.برای رسیدن به این اهداف، پلتفرم مجموعه ای از عملیات را در اختیار می گذارد که می تواند  به روش های دلخواه برای واقعی سازی  روش های توسعه فرایند های مختلف ترکیب و تلفیق شود. عملیات شامل روش های آنالیز سنتی  نظیر تولید درخت خطا همراه با قابلیت های تایید خصوصیات کنترل مدل علاوه بر قابلیت های ساخت مدل ( تزریق اتوماتیک خرابی بر اساس کتابخانه حالات خرابی از پیش تعیین شده) و قابلیت های پایش است که موجب بهبود تبادل اطلاعات شده و منجر به  نگهداری آسان تر سیستم خواهد شد. مزیت های اصلی استفاده از روش و پلتفرم ESACS شامل تلفیق بین تیم های ایمنی و طراحی، مکانیزاسیون فعالیت های مربوط به  صحت سنجی و آنالیز های ایمنی سیستم ها در محیط یکنواخت و پشتیبانی استفاده از روش های مختلف تولید ( رویکرد تجمعی، بر اساس انتشار  مدل سیستم به طور تکراری در  سطوح مختلف جزییات) هستند.

• بخشی از مقاله انگلیسی:

Introduction In the development cycle of a complex system, it is possible to identify a certain number of steps each involving different processes and tasks that the system development team has to carry out. In the classic waterfall model, the principal phases are: requirements analysis and specification, design, implementation, testing, analyses and maintenance. In the last decades, many variations of this model were proposed. Some of these are based on virtual prototyping and simulation, incremental development, reusable software and automated synthesis. As specification errors and misconceptions found in later phases of the system development cycle are extremely expensive to fix, it is evident that meticulous comprehension of the system and of its behaviour should be carried out as early as possible in the development cycle. Dedicated languages are therefore used in the requirements capturing phase to build a model of the system, and model checking techniques are used to analyse it in detail. The availability of a model is important for all participants in the system development; for example, if an unambiguous and executable model is available early on, customers and subcontractors can become aware with it, and can approve or improve the functionality and behaviour of the system before investing heavily in the implementation stages. Precise and detailed models are also in the best interest of the designers, analysers and testers of the system. If the system under development is a safety critical system, in parallel to the standard development process described above, it is necessary to carry out a set of activities – safety assessment activities – whose goal is assessing the robustness of the system in degraded situations, that is, when some of the components are not working as expected. The phases, activities, and outputs of the safety assessment process are coded by various standards (e.g., ARP4754). The first step is defining the safety requirements of the system, that is, the minimum safety levels that the system must achieve. As an example, a safety requirement may be something like: “no single failure shall yield to a loss of a given output”. The next step is assessing the safety of the architecture, by determining what are the combinations of failures of components that may cause a safety requirement to be violated. During this activity, safety engineers produce, e.g., fault trees, that are compact representations of the combination of failures leading to the violation of a given safety requirement [VGRH81]. System certification typically requires the probability of such combination of failures to be below a given threshold. The traditional safety verification process, that relies on the ability of the safety engineer to understand and to foresee the system’s behaviour, is very difficult to carry out and error prone when dealing with highly complex systems. Moreover, even when formal methods are used during system development, the information passed to the safety engineer is still transmitted by means of informal specifications and the communication between system design and safety assessment activities can be seen as an “over the wall process” [FMPN94]. A solution to these issues is to perform the safety assessment analysis in some automated way, directly from the formal system model coming from the design engineer. This approach is being developed and investigated in ESACS (Enhanced Safety Assessment for Complex Systems), a European-Union-sponsored project in the area of safety analysis, involving several research institutions and leading avionics and aerospace industrial companies. The methodology developed within the ESACS project is supported by state-of-the-art and commercial tools for system modelling and safety analysis. Furthermore, the effectiveness of the ESACS methodology is being tested against a set of real-world industrial case studies. In this paper we report on the application of the ESACS methodology to one of such industrial case studies, namely the Secondary Power System (SPS, for short) of the Eurofighter Typhoon and we report on the obtained results. Outline of the paper The paper is structured as follows: in the next section we present the ESACS methodology and platform; in Section 3 we present the SPS case study and discuss our experience. In Section 4 we report on related work and in Section 5 we draw some conclusions and discuss future work.