Automated Greenhouse Gas Data Collection, Visualisation and Reporting
Notice bibliographique
Résumé
Abstract In 2008/2009 Apache Energy Limited (AEL) triggered the Australian National Greenhouse and Energy Reporting (NGER) Act threshold, requiring AEL to compile and report energy and emissions datasets for the financial year. This was in addition to the Apache Corporate calendar year emissions reporting requirements. Initially this was managed with EXCEL spread sheets, and the process was cumbersome and time consuming. Today I’m going to present the way in which the use of simple technology has enabled Apache to streamline its GHG reporting. In 2010 AEL developed real time, online flare/emissions pages, using the visualisation software BabelFish. The real time data is collected from the offshore Distributed Control System (DCS) using an automatic data collector, and it is stored in a PI (Process Information) Historian database. These visualisation pages "talk" to the PI Historian database and give real time data for the volume of CO2 equivalent emitted from all sources, for all the facilities operated or controlled by AEL. All data, trends, and year-end forecasts are available for anyone with access to see ‘real time’. The data stored in the PI Historian reduces the burden in producing emissions reports by capturing month end emissions data within the Production Reporting System (PRS), which can then be used to generate the NGERS report and the Apache corporate emissions report in a matter of minutes as opposed to months. With the arrival of the Clean Energy Legislation, and the tax on carbon emissions, it is imperative that companies have a good understanding of their emissions. Streamlining the reporting process and providing real time emissions data to management will help underpin this understanding.
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 distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,001 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,000 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,000 | 0,001 |
| Science ouverte | 0,000 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
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.
score_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écouleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
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 ».