|
Đòi hỏi
Một đòi hỏi là một
đề xuất được đảm bảo về hệ thống đáng quan tâm. Đòi hỏi có thể đi kèm với
thông tin phụ trợ, ví dụ: thời hạn được đề cập trong đề xuất hay độ không xác
định của đề xuất.
Biện minh, Lập
luận, Bằng chứng và Trường hợp đảm bảo
Biện minh, lập luận,
bằng chứng và trường hợp đảm bảo được định nghĩa cùng đệ quy trong hình này.
Đưa ra một đòi hỏi c, một biện minh j của c là một lý do
tại sao c lại được chọn.
Bình luận: Do vậy,
một biện minh được định nghĩa liên quan tới đòi hỏi c. Một lập luận
(được định nghĩa bên dưới) cũng được định nghĩa liên quan tới một đòi hỏi,
nhưng khác biệt với biện minh bởi một biện minh là một lý do cho việc lựa
chọn một đòi hỏi, trong khi một lập luận là một lý do tạo sao một đòi hỏi là
đúng.
Đưa ra một đòi hỏi c
và một tập bằng chứng es, một lập luận mà đảm bảo c dùng es
được định nghĩa là một lý do tạo sao sự thực của c được suy luận
từ phần chính của bằng chứng trong tập es.
Bằng chứng là cả
một thực tế, mốc, đối tượng, một đòi hỏi hay một trường hợp đảm bảo. Một đòi
hỏi được gọi là một giả định nếu nó xuất hiện trong một trường hợp đảm bảo
như bằng chứng. Phần chính của bằng chứng được định nghĩa dựa trên mẫu bằng
chứng, nếu bằng chứng đó là một thực tế, mốc, đối tượng hay một đòi hỏi, phần
chính của nó là chính nó; nhưng nếu bằng chứng đó là một trường hợp đảm bảo ao, phần chính của nó
là đòi hỏi của ao.
Bình luận: Bằng
chứng phải được chỉ rõ bên dưới trong Hình 1 rằng: bằng chứng của một trường
hợp đảm bảo được dùng bởi một lập luận của trường hợp đảm bảo đó nhằm đảm bảo
rằng đòi hỏi của nó được kéo dài.
Bình luận: Một đòi
hỏi xuất hiện như một bằng chứng được gọi là một giả định bởi bằng chứng đó
là một đề xuất với bất kỳ lý do tại sao lại đúng. Khi một lý do cho sự thật
được nêu ra, lý do được mong đợi rằng một trường hợp đảm bảo mà lập luận của
nó là lý do đó, được xây dựng và được nêu như bằng chứng thay vì cung cấp chỉ
một đòi hỏi như bằng chứng.
Một trường hợp đảm
bảo được định nghĩa là một bội số bốn của một đòi hỏi c, một biện minh
j của c, một tập bằng chứng es và một lập luận g mà
đảm bảo c dùng es. Cho a = (c,j,es,g) là một
trường hợp đảm bảo; c được định nghĩa là đòi hỏi của a; tương
tự j được định nghĩa là biện minh của a, es là tập bằng
chứng của a, và g là lập luận của a.
Bình luận: Định
nghĩa các trường hợp đảm bảo dựa trên các lập luận, định nghĩa các lập luận
dựa trên bằng chứng và định nghĩa bằng chứng dựa trên các trường hợp đảm bảo.
Các định nghĩa này tuy không vòng vo, nhưng cùng đệ quy với các định nghĩa
khác.
Bình luận: Đối với
người dùng theo định hướng toán học, định nghĩa đệ quy sau của tập các trường
hợp đảm bảo có thể giúp đỡ phần nào. Tập trường hợp đảm bảo A và tập
bằng chứng E được định nghĩa bởi các phép toán đệ quy sau:
A0 = C × {j0 Î J(c0) | c0 Î C } × ωf (E) × {g0 Î G (c0, es0) | c0 Î C, es0 Î ωf (E)}
A
= {(c,
j, es, g) Î A0 | j Î J(c), g Î G (c, es)}
E
= F + D + O + C + A
trong đó:
J(c) tập tất cả biện
minh đối với một đòi hỏi c;
C tập đòi hỏi;
ωf (E) tập tất cả tập con
hữu hạn của E (tập tổng hữu hạn của E);
G (c0, es0) tập các lập luận
đảm bảo một đòi hỏi co sử dụng một tập bằng chứng eso;
F tập thực tế, D là
tập thời gian;
O tập đối tượng;
M × N sản phẩm trực tiếp
của M và N, với bất kỳ tập M và N nào; và
M + N nhóm
phân biệt (tổng trực tiếp) của M và N và bất kỳ tập M và
N nào.
|
Hình
1 - Cấu trúc của trường hợp đảm bảo (tham khảo)
Các đòi hỏi sau áp
dụng cho cấu trúc của một trường hợp đảm bảo:
a) Một trường hợp đảm
bảo phải có một hay nhiều các đòi hỏi mức cao là mục đích tối thượng của các
lập luận của chính trường hợp đảm bảo.
CHÚ THÍCH Nhiều đòi
hỏi mức cao tương đương với việc kết nối của chúng.
b) Một lập luận phải
được hỗ trợ bởi một hay nhiều đòi hỏi, bằng chứng hay giả định.
CHÚ THÍCH 1 Một lập
luận được sử dụng nhằm thể hiện cách thức mà các thành phần làm nền tảng trực
tiếp liên quan tới một hay một tập đòi hỏi. Tập các thành phần làm nền tảng với
mỗi lập luận bao gồm: một tập bằng chứng, giả định và đòi hỏi mức thấp hơn.
CHÚ THÍCH 2 Khi một
lập luận không thể hỗ trợ trực tiếp các lập luận khác, một lập luận mức thấp
hơn nên gắn với một đòi hỏi mức thấp hơn mà chuyển sang gắn liền với với lập
luận cấp cao hơn.
c) Một đòi hỏi phải
được hỗ trợ không chỉ bởi một lập luận, hoặc một hay nhiều đòi hỏi, hoặc giả
định.
CHÚ THÍCH Mọi đòi hỏi
trong một trường hợp đảm bảo yêu cầu hỗ trợ dưới nhiều mẫu khác nhau. Do đó,
một đòi hỏi thì không bao giờ là một thành phần bên dưới của một trường hợp đảm
bảo. Một (và chỉ một) lập luận có thể được dùng để hỗ trợ một đòi hỏi. Nói cách
khác, một đòi hỏi có thể hỗ trợ (trực tiếp và không thông qua lập luận) bởi một
vài tập bằng chứng, giả định hoặc các đòi hỏi mức thấp hơn.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
CHÚ THÍCH Một đòi
hỏi, lập luận, bằng chứng hay giả định đơn lẻ có thể được dùng để hỗ trợ nhiều
thành phần.
6.3. Đòi hỏi
6.3.1. Mẫu đòi hỏi
Đòi hỏi phải là một
mô tả đúng-sai nhằm chỉ ra các giới hạn giá trị của một đặc tính được định
nghĩa rõ ràng - được gọi là đặc tính của đòi hỏi, các giới hạn về độ không xác
định về giá trị của đặc tính đáp ứng các giới hạn của đòi hỏi và các giới hạn
về điều kiện mà đòi hỏi này được áp dụng.
6.3.2. Nội dung của
đòi hỏi
Một đòi hỏi phải có
các nội dung được yêu cầu và có thể có nhiều nội dung tùy chọn được chỉ ra
trong danh sách sau:
a) Đặc tính của đòi
hỏi (yêu cầu).
b) Các giới hạn dựa
trên giá trị của đặc tính liên quan tới đòi hỏi (ví dụ: trong dải của nó) (yêu
cầu).
c) Các giới hạn dựa
trên độ không xác định của giá trị đặc tính đáp ứng giới hạn của nó (yêu cầu).
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
e) Độ không xác định
của thời hạn liên quan (tùy chọn)
f) Các giới hạn dựa
trên điều kiện mà đòi hỏi được áp dụng (yêu cầu)
g) Độ không xác định
của điều kiện liên quan (tùy chọn).
h) Nếu một đặc tính
trong một đòi hỏi áp dụng cho một vài tập con của các hệ thống, sản phẩm hay
các phần tử của chúng, việc xác định bao gồm: các phiên bản hoặc trường hợp
liên quan (yêu cầu có điều kiện).
i) Các hệ quả hoặc
rủi ro nếu liên quan tới đòi hỏi (yêu cầu có điều kiện).
CHÚ THÍCH 1 Thuật ngữ
“giới hạn” được dùng để đáp ứng nhiều tình huống có thể tồn tại. Các giá trị có
thể là một hay nhiều giá trị đơn lẻ, một hay nhiều dải giá trị, hoặc đa chiều.
Ranh giới của các giới hạn này đôi khi bao gồm việc phân phối khả năng xảy ra,
được tăng cường hoặc có các khía cạnh không rõ ràng khác.
CHÚ THÍCH 2 Độ không
xác định cũng có thể liên quan tới khoảng thời gian áp dụng và các điều kiện đề
ra. Các đòi hỏi cụ thể không cần bao gồm tất cả độ không xác định có thể và chỉ
bao gồm chủ yếu một. Trong trường hợp chính xác, độ không xác định có thể là 0.
6.3.3. Phạm vi của
điều kiện
Các điều kiện bao gồm
bất kỳ thời hạn được quy định nào, được bao trùm bởi việc kết hợp các thành
phần của trường hợp đảm bảo hỗ trợ một đòi hỏi phải cùng bao trùm các điều kiện
đó, bao gồm bất kỳ giới hạn được quy định nào cho đòi hỏi được áp dụng.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Bởi việc chọn lựa một
đòi hỏi mức cao và đặc tính của nó là quan trọng để đáp ứng mục tiêu của một
trường hợp đảm bảo và thúc đẩy quá trình xây dựng của trường hợp đảm bảo, một
đòi hỏi mức cao phải có một biện minh cho lựa chọn của nó.
CHÚ THÍCH Biện minh
cho đòi hỏi mức cao là một cách thức để kết nối rủi ro giữa các bên liên quan
của hệ thống và cho việc ghi thỏa thuận.
6.4. Lập luận
6.4.1. Đặc tính của
lập luận
Một lập luận được
dùng để thể hiện cách thức các thành phần làm nền tảng trực tiếp mà liên quan
tới một hay một tập đòi hỏi. Một lập luận có thể đặc biệt hữu ích nếu nó dưới
dạng một tính toán kỹ thuật hay bằng chứng logic mà không nằm dưới dạng một
trường hợp đảm bảo.
Một lập luận có các
đặc tính sau:
a) Lập luận phải chỉ
ra theo một cách thức mà sử dụng các thành phần trực tiếp bên dưới nó.
b) Lập luận phải đạt
được một hay nhiều kết luận liên quan tới mỗi đòi hỏi mà nó hỗ trợ.
c) Lập luận phải xây
dựng độ không xác định của mỗi kết luận đạt được.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
6.4.2. Biện minh về
phương pháp luận
Lập luận phải có một
biện minh tương ứng cho giá trị hay chất lượng của phương pháp luận của lập
luận (ví dụ: tính toán hoặc tranh cãi).
CHÚ THÍCH Nhiều
phương pháp luận có thể sử dụng trong các lập luận. Các phương pháp này bao gồm
các công cụ sử dụng, thay đổi khả năng áp dụng, nguồn, dẫn tới sự chính xác và
độ không xác định và dễ dàng sử dụng. Các lập luận được dùng để hỗ trợ hoặc
giảm thiểu các đòi hỏi. Các đòi hỏi, bằng chứng và các giả định làm nền tảng
cho một lập luận có các trạng thái không xác định liên quan tới chúng và lập
luận có thể ảnh hưởng tới độ không xác định của đòi hỏi sử dụng lập luận.
6.5. Bằng chứng
6.5.1. Nội dung của
bằng chứng
Bằng chứng phải bao
gồm dữ liệu hay thông tin rõ ràng.
CHÚ THÍCH Có nhiều
loại bằng chứng tồn tại. Giữa các báo cáo kinh nghiệm, lịch sử, quan sát, đo
đạc, thử nghiệm, các kết quả đánh giá và tuân thủ, việc hiệu chỉnh của lý do
thiết kế, phân tích, so sánh các tạo tác, đánh giá, các sai sót và các đảm bảo
chất lượng và dữ liệu lĩnh vực khác. Bằng chứng có thể đã tồn tại, được tạo mới
hoặc được thu thập, lên kế hoạch dự kiến. Bằng chứng nên hỗ trợ hoặc giảm thiểu
các đòi hỏi trong trường hợp đảm bảo. Nội dung bằng chứng có thể khá lớn và
phải được tổ chức, định vị và được thể hiện để có thể hiểu được đối với các cá
nhân đánh giá, phê duyệt hay trực tiếp sử dụng bằng chứng.
6.5.2. Thông tin liên
quan
Bằng chứng phải bao
gồm hoặc có trong nó thông tin liên quan:
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
b) Phạm vi áp dụng.
c) Độ không xác định,
bao gồm khả năng tin cậy của nguồn thông tin của bằng chứng (ví dụ: độ xác
thực, tin cậy và hoàn chỉnh) và độ đo lường chính xác.
CHÚ THÍCH Thông tin
có thể chia thành nhiều dạng bao gồm: một hay nhiều trường hợp đảm bảo hoặc
thành phần.
6.5.3. Giả định liên
quan
Bất kỳ giả định nào
liên quan tới bằng chứng phải được bao gồm trong trường hợp đảm bảo.
6.6. Giả định
6.6.1. Mẫu giả định
Một giả định phải
chia thành một đòi hỏi và một lý do ứng với nó.
6.6.2. Nội dung của
giả định
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Loại giả định thứ ba
vốn đã không được kế thừa đúng theo ngữ cảnh, nói đúng hơn nó là một đòi hỏi không
được đảm bảo hoàn toàn bởi bằng chứng. Loại giả định này phải:
a) Bao gồm một đòi
hỏi và một lý do cho nó.
b) Bao gồm một chỉ
báo, định danh hoặc mô tả của cơ sở của việc đánh giá độ không xác định liên quan
đến sự thật của giả định.
CHÚ THÍCH Đối với kết
quả tốt nhất, các giả định này phải có một hay nhiều đặc tính sau: có độ không
xác định hoặc rủi ro thấp bởi chúng ít quan trọng hơn trong lập luận; có một
tác động yếu trong lập luận; có ảnh hưởng yếu trong các giá trị quan trọng hay
hệ quả, hoặc là một vài trong số đó.
6.6.3. Bằng chứng
liên quan
Nếu một giả định được
đảm bảo hoặc cam kết một phần theo bằng chứng, bằng chứng đó phải tương ứng với
nó.
6.7. Biện minh
Một đòi hỏi mức cao
có một biện minh cho việc chọn lựa của chính nó (Điều 6.3.4) và một lập luận có
một biện minh cho phương pháp lập luận của chính nó (Điều 6.4.2)
6.8. Kết hợp các
trường hợp đảm bảo
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
CHÚ THÍCH Một phần
của một trường hợp đảm bảo có thể cũng là một phần của các trường hợp đảm bảo
khác.
7. Kết quả được yêu
cầu của việc sử dụng tiêu chuẩn
7.1. Kết quả
Ứng dụng của tiêu
chuẩn này có các kết quả sau:
a) Một trường hợp đảm
bảo đáp ứng các yêu cầu của Điều 6 phải được cung cấp như một phần tử của hệ
thống.
CHÚ THÍCH Là một phần
tử của hệ thống, trường hợp đảm bảo chủ yếu được mong đợi nhằm phân tán trong
hệ thống và được duy trì khi hệ thống được bảo trì.
b) Một ánh xạ logic
đáp ứng các yêu cầu của Điều 7.2 phải được cung cấp như một phần của trường hợp
đảm bảo.
c) Các biên bản ghi chép
việc đáp ứng trọn vẹn các yêu cầu của tiêu chuẩn này phải được xác định và tham
chiếu theo trường hợp đảm bảo.
d) Việc xác định một
hay nhiều thực thể khẳng định sự phù hợp phải được cung cấp trong trường hợp đảm
bảo.
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
Một trường hợp đảm
bảo phải:
a) Bao gồm một ánh xạ
rõ ràng đối với các thành phần và quan hệ trong Điều 6.
b) Bao trùm tất cả
nội dung được quy định trong Điều 6 ngoại trừ việc biện minh bằng văn bản được
cung cấp để làm việc khác.
CHÚ THÍCH 1 Bởi ánh
xạ này phải đối chiếu từ các trường hợp đảm bảo được phát triển trong một vài
đặc tính riêng và tối ưu hóa nhiều ký hiệu, việc ánh xạ này có thể ở bất kỳ
dạng rõ ràng nào.
CHÚ THÍCH 2 Việc ánh
xạ có thể gán một ý nghĩa và ánh xạ tới một thành phần đã biến mất nếu ánh xạ
đó là rõ ràng. Ví dụ: nếu một loại không xác định cụ thể không được quy định rõ
ràng thì ánh xạ đó có thể chỉ ra rằng điều này tương đương với việc ánh xạ được
quy định và bằng 0.
Thư
viện tài liệu tham khảo
[1] Greenwell,
William S., John C. Knight, and Jacob J. Pease, “A Taxonomy of Fallacies in
System Safety Arguments” 24th International System Safety Conference,
Albuquerque, NM, tháng Tám 2006
[2] IEC 60300, Dependability
management (tất cả các phần)
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
[4] IEC 61511,
Functional safety - Safety instrumented systems for the process industry sector
(tất cả các phần)
[5] IEC 61882:2001,
Hazard and operability studies (HAZOP studies) - Application guide
[6] IEEE Std
1228-1994, IEEE Standard for Software Safety Plans
[7] ISO/IEC
12207:2008, Systems and software engineering - Software life cycle processes
[8] ISO/IEC
15288:2008, Systems and software engineering - System life cycle processes
[9] ISO/IEC 15408,
Information technology - Security techniques - Evaluation criteria for IT
security (tất cả các phần)
[10] ISO/IEC 15504,
Information technology - Process assessment (tất cả các phần)
[11] ISO/IEC TR 15443,
Information technology - Security techniques - A framework for IT security
assurance (tất cả các phần)
[12] ISO/IEC 16085:2006,
Systems and software engineering - Life cycle processes - Risk management
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
[14] ISO/IEC 19770,
Information technology - Software asset management (tất cả các phần)
[15] ISO/IEC
21827:2008, Information technology - Security Engineering - Capability
Maturity Model (SSE-CMM)
[16] ISO/IEC 25010,
Systems and software engineering - Systems and software Quality Requirements
and Evaluation (SQuaRE) - Quality models1
[17] ISO/IEC 25012:2008,
Software engineering - Software product Quality Requirements and Evaluation
(SQuaRE) - Data quality model
[18] ISO/IEC 25020:2007,
Software engineering - Software product Quality Requirements and Evaluation
(SQuaRE) - Measurement reference model and guide
[19] ISO/IEC 25030:2007,
Software engineering - Software product Quality Requirements and Evaluation
(SQuaRE) - Quality requirements
[20] ISO/IEC 25040,
Systems and software engineering - Systems and software Quality Requirements
and Evaluation (SQuaRE) - Evaluation process
[21] ISO/IEC 25051:2006,
Software engineering - Software product Quality Requirements and Evaluation
(SQuaRE) - Requirements for quality of Commercial Off-The-Shelf (COTS) software
product and instructions for testing
[22] ISO/IEC 26702:2007,
Systems engineering - Application and management of the systems engineering
process
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
[24] ISO/IEC
Directives, Part 2: Rules for the structure and drafting of International
Standards, xuất bản lần thứ 5, 2004
[25] KELLY, T. “Arguing
Safety - A Systematic Approach to Managing Safety Cases”, Doctoral Thesis - University
of York: Department of Computer Science. tháng Chín 1998
[26] Ministry of Defence.
Defence Standard 00-42 Issue 2, Reliability and Maintainability (R&M) Assurance
Guidance. Part 3, R&M Case, 6 tháng Sáu 2003
[27] Ministry Of
Defence. Defence Standard 00-55 (PART 1)/Issue 4, Requirements for Safety
Related Software in Defence Equipment Part 1: Requirements, tháng Mười hai 2004
[28] Ministry of
Defence. Defence Standard 00-55 (PART 2)/Issue 2, Requirements for Safety
Related Software in Defence Equipment Part 2: Guidance, 21 tháng Tám 1997
[29] Ministry of Defence.
Defence Standard 00-56. Safety Management Requirements for Defence Systems.
Part 1. Requirements Issue 4, 01 tháng Sáu 2007
[30] Ministry of Defence.
Defence Standard 00-56. Safety Management Requirements for Defence Systems.
Part 2: Guidance on Establishing a Means of Complying with Part 1 Issue 4, 01
tháng Sáu 2007
[31] SafSec Project.
SafSec Methodology: Guidance Material: Integration of Safety and Security. Có
sẵn tại: http://www.altran-praxis.com/safSecStandards.aspx
[32] SafSec Project. SafSec
Methodology: Standard: Integration of Safety and Security. Có sẵn tại: http://www.altran-praxis.com/safSecStandards.aspx
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
[34] UK CAA. CAP 670
Air Traffic Services Safety Requirements. UK Civil Aviation Authority Safety Regulation
Group, 18 tháng Hai 2010
[35] UK CAA CAP 760
Guidance on the Conduct of Hazard Identification, Risk Assessment and the Production
of Safety Cases For Aerodrome Operators and Air Traffic Service Providers, 13
tháng Một 2006
MỤC
LỤC
Lời nói đầu
1. Phạm vi áp dụng
2. Sự phù hợp
3. Tài liệu viện dẫn
4. Thuật ngữ và định
nghĩa
...
...
...
Bạn phải
đăng nhập hoặc
đăng ký Thành Viên
TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.
Mọi chi tiết xin liên hệ:
ĐT: (028) 3930 3279 DĐ: 0906 22 99 66
6. Cấu trúc và nội
dung của trường hợp đảm bảo
7. Kết quả được yêu
cầu của việc sử dụng tiêu chuẩn
Thư mục tài liệu tham
khảo
1
Đã được xuất bản.