MétaCan
Menu
Retour à la cohorte
Enregistrement W6991917147

I thought I had the right roadmap for implementing a safety system; help!

2017· other· en· W6991917147 sur OpenAlexaff

Notice bibliographique

RevueOakTrust (Texas A&M University Libraries) · 2017
Typeother
Langueen
Domaine
Thématique
Établissements canadiensSuncor Energy (Canada)
Organismes subventionnairesnon disponible
Mots-clésScope (computer science)DeliverableIEC 61508Process (computing)ScheduleFunctional safetySafety caseProject management
DOInon disponible

Résumé

récupéré en direct d'OpenAlex

International standards IEC 61511 and IEC 61508 provide guidance for the safety system lifecycle phases.Armed with this knowledge, the safety design engineer may feel that he/she can tackle any project.However, the scope of a safety system project can vary considerably.The SIS may be part of a new multibillion dollar process plant, a facility revamp or just involve the addition of a few safety functions to an existing installation.Even though the basic steps may be similar, the execution will vary considerably depending on the overall scope and makeup of the project.Furthermore, the overall project schedule and resourcing are most often governed by scope other than the safety system.A large project may take four to seven years from conception to startup.Essentially, the safety engineer has to navigate many interfaces in order to formulate a solid SIS design basis (i.e., the safety requirements specification).It is important to understand the complexity that arises from these interfaces since they need careful management.We need to understand how a project works, what are the critical interfaces for the safety system and when to make timely decisions.noted that only very high level activities and deliverables are normally accepted for level 2 schedules. P&ID design review (SIS groups)The lead process engineer should confirm the methodology for reviewing SIS groups during the P&ID reviews, in preparation for PHA.This activity will support the development of cause & effect drawings, shutdown keys, etc which are commonly used in the development of the SIS application logic.Key interfaces disciplines include HSE/risk management, process licensor, lead control systems engineer and functional safety engineer. Establish PHA ProcedureHSE/risk management should issue the PHA process and guidelines.This process will be followed to identify hazards and potential SIFs.The plan should also include preliminary PHA reviews and assessment of mechanical package safety systems.Key interfaces include the process licensor, end-user, lead process engineer and functional safety engineer. Define project risk criteria & SIL allocation procedureHSE/risk management should obtain and review tolerable risk criteria & acceptable spurious trip rate (STR) data and risk ranking methodology applicable to the facility from the enduser.Under normal circumstances the HSE/risk management group would receive this from the appropriate client organization.This information usually includes the SIL allocation methodology. Plant operating narrative & safeguarding philosophyThe SIS design needs to include the plant equipment design requirements for operational availability , planned maintenance shutdown/turnaround periods and bypass philosophy.The lead process engineer should confirm this information at an early stage of design.Development of this philosophy would be required for the PHA, SIL allocation and the SRS.Key interfaces include the process licensor, end-user , lead control systems engineer and functional safety engineer. Code requirements and specialty systemsThe functional safety engineer should review SIS implementation philosophy for high integrity pressure protection systems (HIPPS) and burner management systems (BMS).This work should consider end-user operating standards and requirements of the local authorities having jurisdiction.Key interfaces include the process licensor, lead process engineer, end-user , lead control systems engineer and fired heater mechanical engineer. Establish safety requirements specificationThis is the fundamental document used to collect information about and hence define the SIS.The function safety engineer should develop an agreed format for the SRS.This ensures that important inputs to the SIS design from the disciplines are received in a timely manner.Hazop reports, SIL assignments for each SIF, plant operating narratives, safeguarding philosophy, cause & effect drawings and range, alarm & trip Lists together with the SIS narratives are crucial elements to support the SRS.Key interfaces include HSE/risk management, process licensor, lead process engineer, enduser, lead control systems engineer and lead mechanical engineer. Device Failure DataThe functional safety engineer should ensure that SIS certification data for procured instruments is obtained (e.g., SIL certificates, relevant end-user "proven in use" device data, safety assessment reports & safety manuals, generic industry data).Functional safety engineer should also validate device selection against end-user approved vendor list.Furthermore, he/she should confirm that use of diagnostics (e.g., partial stroke testing, external comparison) is in accordance with operations and maintenance procedures.Key interfaces include process licensor, end-user, lead control systems engineer and mechanical engineer for package equipment (e.g., compressors and fired heaters). SIL verificationThe functional safety engineer should confirm SIL verification methodology including process interface implications for the instrumentation and end-user acceptable calculation software.Constraints in relation to availability of the plant for offline proof testing (i.e., plant turn-around period) should also be identified.Key interfaces include process licensor, end-user, lead control systems engineer and lead process engineer.Who is involved in the safety plan?

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Comment cette classification a été obtenuedéplier

Prédiction machine sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.

score de la tête « metaresearch » (Codex)0,006
score de la tête « metaresearch » (Gemma)0,029
Version: metacan-v3-hybrid-931329e0061cStatut de validation: machine_predicted_unvalidated
Catégories candidatesaucune
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Sans objet · Signal consensuel: Sans objet
GenreSignal candidat: Autre · Signal consensuel: aucune
Score de désaccord entre enseignants0,282
Score d'incertitude au seuil0,944

Scores du classifieur distillé par catégorie (deux têtes)

CatégorieCodexGemma
Métarecherche0,0060,029
Méta-épidémiologie (sens strict)0,0020,001
Méta-épidémiologie (sens large)0,0010,002
Bibliométrie0,0020,001
Études des sciences et des technologies0,0070,003
Communication savante0,0070,012
Science ouverte0,0020,010
Intégrité de la recherche0,0070,014
Charge utile insuffisante (le modèle a refusé de juger)0,2820,260

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,015
Tête enseignante GPT0,219
Écart entre enseignants0,204 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle

Classification

machine, non validée

Prédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.

Les modèles n’ont appliqué aucune catégorie : rien dans la taxonomie ne correspondait à ce travail.
Devis d'étudeSans objet
Domainenon disponible
GenreAutre

Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».

En bref

Citations0
Publié2017
Routes d'admission1
Résumé présentoui

Explorer davantage

Même revueOakTrust (Texas A&M University Libraries)Travaux en français237 207