Taksi išsiuntimo informacinė sistema. Dispečerinio valdymo sistema Kuriama dispečerinė informacinė sistema

Automatizuota vieningos tarnybos dispečerinės tarnybos (AS EDDS) sistema yra sistema, skirta teikti informacinę pagalbą kasdieniniam RSChS valdymo organui savivaldybės lygmeniu. AS EDDS apima šiuos struktūrinius posistemius: automatikos įrangos kompleksus (CAS):

  • KSA EDDS savivaldybė; EDDS sąveikos (KSAV) su savivaldybės žinybinėmis budinčiomis dispečerinėmis tarnybomis (DDS), potencialiai pavojingų objektų dispečerinėmis tarnybomis, gyventojų gyvybę palaikančiomis priemonėmis ir masinio žmonių susibūrimo objektais;
  • Pavaldžių priešgaisrinės gelbėjimo, paieškos ir gelbėjimo bei greitosios pagalbos padalinių (toliau – pavaldūs padaliniai) operatyvinės tarnybos (ODS) KSA;
  • transporto priemonėse dislokuotų pavaldžių padalinių mobilioji KSA (MCSA).

Siekiant efektyviai išspręsti pavestas užduotis, kaip EDDS AS dalis sukuriamos atitinkamos funkcinės ir pagalbinės posistemės (žr. pav.). AS EDDS funkciniai posistemiai apima:

  • automatizuota dispečerinė sistema (ADS), skirta informacijai iš gyventojų ir organizacijų rinkti apie gaisrus, stichines ir žmogaus sukeltas nelaimes, taip pat pavaldžių padalinių operatyviniam valdymui;
  • Sprendimų palaikymo sistema (DSS), kuri padeda teikti informacinę pagalbą valdymo sprendimų priėmimo procesams reaguojant į ekstremalias situacijas;
  • valdymo dokumentų rengimo sistema (SPUD), kurios funkcijos apima formalizuotų organizacinių, administracinių ir atskaitomybės informacinių dokumentų rengimą;
  • automatizuota gyventojų konsultavimo paslaugų sistema (ASCO), skirta piliečiams internetu teikti informacinę ir informacinę pagalbą gyvybės saugos užtikrinimo klausimais.

Pagalbinės posistemės apima:

  • informacijos ir navigacijos posistemis (INS), skirtas pavaldžių padalinių transporto priemonių vietai ir būklei nustatyti;
  • automatizuotas perspėjimo posistemis (ASO) – greitam ir patikimam perspėjimo signalų ir informacijos generavimui bei pristatymui pareigūnams, o prireikus ir gyventojams avarinėse zonose;
  • veiklos palaikymo posistemis (ESS) - apsaugoti konfidencialią informaciją ir jos apdorojimo priemones, taip pat spręsti patikimo AS EDDS veikimo užtikrinimo problemas;
  • integruotas ryšių ir duomenų perdavimo posistemis (ISCS), būtinas budinčių ir dispečerinių tarnybų bei pavaldžių padalinių keitimuisi informacija.

ISPD apima du potinklius: fiksuoto pagrindinio ryšio ir duomenų tinklą, sukurtą naudojant laidinį ryšį, ir mobiliojo ryšio bei duomenų tinklą, organizuojamą naudojant radijo kanalus.

AS EDDS funkcinės užduotys užtikrina šių pagrindinių valdymo funkcijų automatizavimą:

  • norminės ir informacinės informacijos apie gelbėjimo operacijų objektus, pavaldžius padalinius, jų atsakomybės teritorines zonas formavimas ir tvarkymas (išvykimo grafikai arba pajėgų ir priemonių pritraukimo planai);
  • rinkti ir apibendrinti informaciją iš pavaldžių padalinių apie budintį personalą ir esamos technikos būklę (kovinis užrašas), stebėti jų pasirengimą atlikti pavestas užduotis;
  • gauti pranešimus iš gyventojų ir organizacijų apie gaisrus, avarijas, katastrofas ir stichines nelaimes ir įvesti juos į duomenų bazę;
  • apdoroti gyventojų ir organizacijų pranešimus apie gaisrus, avarijas, katastrofas ir stichines nelaimes, t. nustatyti dalyvaujančių priešgaisrinių gelbėjimo pajėgų ir priemonių sudėtį, numatytą išvykimo grafike (pajėgų ir priemonių pritraukimo planas), taip pat praneštos sąveikaujančios DDS sudėtį;
  • įsakymų (vaučerių) išvykimui ir turimos informacijos apie situaciją rengimas dalyvaujantiems priešgaisrinės paieškos ir gelbėjimo padaliniams;
  • duomenų apie gaisrą, nelaimingą atsitikimą, katastrofą ar stichinę nelaimę pristatymas dalyvaujančiam DDS;
  • pagalba priimant valdymo sprendimus gaisro, avarijos ar stichinės nelaimės padariniams likviduoti;
  • nuolatinis duomenų apie dalyvaujančių jėgų ir priemonių veiksmus, avarijų likvidavimo ar gaisro gesinimo eigą rinkimas ir sintezė;
  • nuolatinė informacija apie avarinių situacijų likvidavimo ar sąveikaujančių DDS gaisro gesinimo eigą;
  • operatyvinių ataskaitų apie ekstremalias situacijas rengimas aukštesnėms institucijoms;
  • stebėti EDDS budinčio dispečerinio personalo veiksmus.

EDDS AS naudoja programinę ir techninę įrangą, kuri užtikrina: kompiuterinį-telefoninį išsiuntimo kompleksų integravimą su privačiu PBX skambučių apdorojimo centrui (CALL centrui) sukurti, telefono skambučių priėmimo ir perdavimo procesų sinchronizavimui bei kortelės formavimui užtikrinti. , įregistravus jame skambinančiojo numerį, jo pavardę ir adresą pagal susiejimą su skambintojo ID įranga ir telefono tinklo abonentų duomenų baze; kortelių apie ekstremalias situacijas ir gaisrus susiejimas su kelių kanalų skaitmenine telefoninių pokalbių įrašymo sistema; funkcinių užduočių sąveika su geografine informacine sistema (EIS), kad geografinė nuoroda būtų rodoma elektroniniame vietovės žemėlapyje; dispečerinių sistemų sąveika su automatine balso pranešimų sistema.

AS EDDS kuriami ir vystomi kaip automatizuotos informacijos ir valdymo sistemos RSChS dalis. Siekdama sumažinti bendras finansines jų sukūrimo išlaidas, Rusijos nepaprastųjų situacijų ministerija įgyvendina vieningą mokslinę ir techninę politiką tokių sistemų kūrimo, diegimo ir tobulinimo srityje.

Šaltiniai: Popovas A.P., Nekhoroševas S.N. Automatizuota operatyvaus išsiuntimo valdymo sistema avarinėse situacijose. Tarptautinio informatizacijos forumo 11-osios mokslinės techninės konferencijos „Saugumo sistemos (SB-2002)“ medžiaga. Rusijos nepaprastųjų situacijų ministerijos Valstybinė priešgaisrinės tarnybos akademija. - M., 2002; Popovas A.P. Pagrindinės Rusijos Federacijos miestų vieningų tarnybos dispečerinių tarnybų tolesnės plėtros kryptys. "Apsaugos sistemos", 2002; Popovas A.P. Pagrindiniai sistemos sprendimai kuriant EDDS. - M., 1999 m.

Šiame straipsnyje nagrinėjamas teigiamas būsto ir komunalinių paslaugų įvedimo poveikis savivaldybių energinio efektyvumo didinimo aspektu.
Būsto ir komunalinių paslaugų sistemoje ilgalaikio turto nusidėvėjimo įverčiai skiriasi. Ministras pirmininkas Vladimiras Putinas neseniai paskelbė apie 50 proc.
Kai kurie ekspertai teigia, kad 70–80 proc. Tai reiškia, kad energijos vartojimo efektyvumas mažės, o žmogaus sukeltų avarijų skaičius ir atitinkamai nuostoliai tik didės.
Žinoma, energijos taupymo lempučių ar automatizuotų energijos suvartojimo apskaitos sistemų (skaitiklių) įdiegimo efektą galima apskaičiuoti iš karto. Tačiau yra technologijų, kurios leis padaryti išvadas, įskaitant tai, ar reikėjo keisti lemputes? Dažnai perspėkite, o nelaimės atveju sumažinkite nuostolius dėl incidento.
Energijos taupymas prasideda ten, kur prasideda apskaita, o automatinė apskaita yra pati išsamiausia, tiksliausia ir efektyviausia, leidžianti valdyti procesą išsiuntimo režimu, atlikti aktualiausias energijos taupymo priemones, stebėti, kaip laikomasi technologinės ir darbo drausmės.
Savivaldybės energinis efektyvumas, taigi ir ekonominis efektas, pasiekiamas formalizuojant ir standartizuojant procesus bei jų skaidrumą, informacijos nedubliavimą, stiprinant organizacinių ir techninių procesų kontrolės funkciją, didinant priimamų sprendimų greitį ir kokybę, ir sumažinti naštą personalui.
Iš to išplaukia, kad tikslumas, greitis ir koordinavimas priklauso nuo to, kiek konkretūs ir aiškiai apibrėžti miesto paslaugų sąveikos nelaimės atveju reglamentai.
Bendros dispečerinės tarnybos atlieka svarbų vaidmenį mažinant jų atsiradimo tikimybę, taip pat sumažinant nuostolius jų lokalizavimo ir pašalinimo metu. Avarinės situacijos reikalauja itin greitų, tikslių ir koordinuotų visų susijusių padalinių ir tarnybų veiksmų. Bet net ir dabartinės veiklos režimu, kokiais įrankiais galima realiu laiku matyti procesus, vykstančius įvairiose miesto gyvybės palaikymo sistemose?
Esu tikras, kad daugelis žmonių supranta, kad tai galima pasiekti įdiegus automatizuotas informacines sistemas. Maskvos srities teritorijoje įdiegtas labai mažas valdymo elementas būsto ir komunalinių paslaugų sektoriuje, vieninga dispečerinė tarnyba, ginkluota automatizuota informacine sistema (AIS GODS), suteikia kumuliacinį poveikį, didinant savivaldybės energijos vartojimo efektyvumą ir tam tikrame mieste ar gyvenvietėje gyvenančių gyventojų gyvybės saugumas. O tai liečia visas savivaldybės gyvenimo sritis, įskaitant galimus energijos nuostolius ir vėlgi galimybes juos sumažinti.
Vieninga informacinė platforma visoms būsto ir komunalinių paslaugų sektoriaus įmonėms ir gyventojams, optimizuojanti ir automatizuojanti duomenų apie vartotojams teikiamas būsto ir komunalines paslaugas bei teikiamus išteklius rinkimo procesą, užtikrina tolesnę šios informacijos sintezę ir analizę, taip pat generuoja ataskaitas. visoms suinteresuotoms valdymo ir kontrolės institucijoms, pradedant nuo būsto apžiūros ir būsto bei komunalinio komplekso tvarkymo iki miesto valdžios ir gyventojų.
Šiam elementui atsiradus miesto valdymo sistemoje, tik pasitelkus organizacines priemones, nereikalaujančias finansinių išlaidų, kuriant miesto administracijos miesto paslaugų sąveikos mechanizmus ir algoritmus, „Sąveikos nuostatų“ patvirtinimas leis sutaupyti daug nervų ir finansinių resursų avarinės ar avarinės situacijos miesto gyvybės palaikymo sistemose atveju.
Ekonominis efektas įdiegus automatizuotą informacinę sistemą priklauso nuo kiekvienos konkrečios savivaldybės specifikos ir, žinoma, nuo priemonių, kurių imamasi remiantis gauta informacija. Kuo didesnis energijos intensyvumas gamyboje (pavyzdžiui, būsto ir komunalinių paslaugų srityje), tuo daugiau neapskaitytų nuostolių, taigi, tuo labiau apčiuopiamas bendras efektas, atsirandantis įdiegus automatizuotą informacinę sistemą, kuri sprendžia problemas ir gerina energijos vartojimo efektyvumą, socialinį ir ekonominį. ir kt.
Net ir miestuose, kuriuose išvystyta infrastruktūra, paslaugų sąveikos trūkumas gali sukelti paniką, laiko praradimą lokalizavimui ir pašalinimui, todėl gali padidėti finansiniai nuostoliai. Yra daug pavyzdžių...
Automatizuota informacinė sistema, kuri yra svarbiausias veikiančios vieningos dispečerinės tarnybos elementas, ne tik slopina staigų gyvenamųjų namų komplekso paslaugų vartotojų užklausų antplūdį, bet ir užpildo šiandieninį informacijos vakuumą būsto srityje. ir komunalines paslaugas.
Deja, nei Rusijos Federacijos valstybinėje programoje „Energijos taupymas ir energijos vartojimo efektyvumo didinimas laikotarpiui iki 2020 m.“, nei juo labiau savivaldybių administracijoms rengiant įvairias programas „Energijos taupymas ir energijos vartojimo efektyvumo didinimas“ nėra galimybės vieningos dispečerinės tarnybos su jos darbo automatizavimu naudojant specialią programinę įrangą diegimas savivaldybės teritorijoje.
Atsižvelgiant į mažas bendras kapitalo investicijas, įgyvendinant projektą, be populiarinimo, būtina papildyti Maskvos srities administracijų parengtas programas su privaloma sąlyga sukurti Būsto ir komunalinių paslaugų tarnybą, būtinai aprūpinant. sukurta paslauga su automatizuota informacine sistema.


Veiksniai, įtakojantys savivaldybės energijos vartojimo efektyvumo didinimą ar mažėjimą

veiksnys

Bet kuri Rusijos gynybos ministerija

MO su GODS būsto ir komunalinėmis paslaugomis ir AIS

Galimybė stebėti būsto fondo būklę realiu laiku

Taip, su galimybe planuoti kapitalinį remontą

Maskvos srities valdymo organų gautos informacijos apie situaciją būsto ir komunalinių paslaugų sektoriuje kokybė

On-line, aukštas

Sąveikos taisyklių prieinamumas

Net ir turint patvirtintus Nuostatus, yra ilgas atsakymo į užklausas laikas ir atitinkamai nuostoliai

Minimalus atsakymo į užklausas laikas, todėl nuostoliai sumažėja

Būsto ir komunalinių paslaugų vartotojų užklausų laiko parametrų kontrolė pagal norminius dokumentus

Galimybė patvirtinti, kad valdymo įmonė nesuteikė paslaugų arba suteikė netinkamos kokybės paslaugas pagal norminius dokumentus

Automatiškai bet kurio AIS vartotojo prašymu

Atlikto kapitalinio remonto efektyvumo vertinimas

Subjektyvus

Nėra užklausų AIS

Valdymo įmonių ir paslaugų organizacijų teikiamų paslaugų kokybės vertinimas

Subjektyvus, neparemtas faktais

Automatiškai prisijungęs, prieinamas visiems AIS naudotojams

Maskvos srities, kaip gyvenamojo ar negyvenamojo turto savininko, materialiniai nuostoliai

Nekontroliuojamas, nesusistemintas, neobjektyvus

Gyventojų materialiniai nuostoliai

Dažniausiai neįvertinta ir nepriimama kompensuoti

Patvirtinta AIS (valdymo įmonės kreipimosi gavimo laikas, kas yra vykdytojas, valdymo įmonės apeliacijos vykdymo laikas, susijusios paslaugos, garso įrašas)

Pakartotiniai gyventojų prašymai

Nekontroliuojamas srautas

Nuo situacijos, kai jie yra, iki jų nebuvimo

Vadovybės vadovų disciplina

Laikas, kurį gyventojas praleidžia apeliaciniam skundui perduoti

Nuo 5 minučių iki 45 minučių

Daugiausia 3 minutes

UES automatizuota dispečerinio valdymo sistema (ADCS) – tai hierarchiškai sukonstruota žmogaus ir mašinos sistema, kuri visoje elektros tinklų aprėptoje teritorijoje leidžia rinkti, transformuoti, perduoti, apdoroti ir rodyti informaciją apie elektros tinklo būseną ir režimą. energetikos sistema, formavimas, pagrįstas surinkta informacija, valdymo komandų perdavimas ir įgyvendinimas, kad sistema (turimų lėšų sąskaita) atliktų patikimo ir ekonomiško tiekimo reikiamos kokybės elektros ir šilumos energija funkcijas. jos vartotojai.

ASDU apima:

· valdyti kompiuterių centrus (UCC) UES centrinėje dispečerinėje, UES ODU, UES centrinėje dispečerinėje, elektros tinklų įmonių (VES) valdymo centrus (DC);

· automatizuotos procesų valdymo sistemos (APCS) elektrinėms, elektrinių ir pastočių blokams;

· centralizuotos ir vietinės automatinio reguliavimo ir valdymo sistemos.

Visus UES ASDU elementus jungia vienas pirminis tinklas, skirtas operatyvinei informacijai ir valdymo komandoms rinkti ir perduoti.

Pagrindinis UVC automatizuotos valdymo sistemos komponentas yra operatyvinės informacijos ir valdymo kompleksai (OIUC), kurių pagalba valdymo centro, valdymo centro ir centrinio valdymo centro dispečerinis personalas atlieka: stebi esamą valdymo centro būklę. valdoma elektros energijos sistema (grandinė, režimai ir valdikliai), retrospektyvi praeities įvykių analizė, perspektyvių režimų įvertinimas . Naudodamasis informacija apie esamą ir būsimą EPS būklę, apkrovų grafikus, remonto darbų planus pagal eksploatacinius pageidavimus, atsižvelgdamas į siuntimo instrukcijų ir direktyvinės medžiagos nurodymus bei rekomendacijas, dispečerinis personalas užtikrina:

· įtakos valdomiems objektams plėtra (aktyviosios ir reaktyviosios galios EPS režimo reguliavimas, įskaitant elektrinės apkrovų grafikų reguliavimą);

· įrangos ir automatinio bei veikimo valdymo įrenginių išvežimas remontui ir grąžinimas eksploatuoti po remonto;



· naujos įrangos ir valdymo įtaisų paleidimas;

· keičiant valdomo tinklo schemą;

· avarinių situacijų likvidavimas ir normalaus EPS veikimo atkūrimas;

· veiklos ataskaitų teikimas;

· operatyvinės informacijos perdavimas.

Valdymo įtakas centrinio valdymo centro, valdymo centro ir centrinio valdymo centro dispečerinis personalas perduoda operatyviai pavaldiems objektams per šių objektų dispečerinį personalą arba tiesiogiai į automatizuotą valdymo sistemą ir energetikos objektų automatinio reguliavimo ir valdymo sistemas naudojant nuotolinį valdymą. prietaisai. Kontrolės veiksmai užtikrina pokyčius:

· elektros tinklų schemos;

· elektrinių ir pastočių įrangos sudėtis;

· automatinio ir operatyvinio valdymo įrankių algoritmai ir nustatymai;

· automatikos įrenginiai;

· elektrinės blokų apkrovos;

· vartotojų apkrovos;

· įtampos elektros tinklo valdymo taškuose (darant įtaką sinchroninių mašinų žadinimui, įjungiant arba išjungiant reaktyviosios galios kompensavimo įrenginius, perjungiant transformatorių žiedus).

Visos valdymo užduotys, užtikrinančios kontrolės sprendimų formavimą, skirstomos į optimizavimą ir vertinimą. Optimizavimo uždavinių sprendimas pasiekiamas įvykdžius bet kurį optimizavimo kriterijų, o vertinimo uždaviniai – tenkinant atitinkamas objekto būsenos lygtis.

Pagrindinis UES valdymo uždavinys – patikimas reikiamos kokybės elektros ir šiluminės energijos tiekimas su minimaliomis jos gamybos, transformavimo, perdavimo ir paskirstymo sąnaudomis, todėl pagrindinis kriterijus formuojant valdymo sprendimus visais UES valdymo hierarchijos lygiais, kai tik galima, yra minimalios išlaidos per nagrinėjamą laikotarpį. Atskirų UES tinklų apimamų teritorijų ekonominė nepriklausomybė gali lemti tai, kad skirtingų UES dalių (IPS, EPS) valdymo kriterijai skirsis ir pareikalaus jų tarpusavio derinimo naudojant specialius algoritmus. Formuojant ir sprendžiant problemas automatizuotose valdymo sistemose, būtina užtikrinti elektros ir šilumos energijos kokybės bei vartotojų elektros ir šilumos tiekimo patikimumo reikalavimus.

ASDU informacinį palaikymą sudaro ši informacija:

· meteorologinės situacijos prognozė – padidinti apkrovos prognozavimo tikslumą ir įrangos gedimo tikimybes;

· agregatų ir elektrinių manevringumo charakteristikas – apskaičiuoti turimą ir darbinę galią bei juose veikiančios ir atsarginės įrangos sudėtį;

· pagrindinės UES įrangos gedimai - jos patikimumo rodikliams apskaičiuoti ir prognozuoti;

· šiluminėms elektrinėms tiekiamo kuro kokybė;

· pagrindinės įrangos (generatorių, elektros linijų, transformatorių ir kt.) būklė - priimti sprendimą dėl išvežimo remontui laiko (nustatoma iš anksto jo diagnostikos metu);

· realiai užtikrintas elektros energijos tiekimo ir šilumos tiekimo vartotojams patikimumas – parinkti optimalius būdus jį didinti;

· vandens pritekėjimo į hidroelektrinių rezervuarus prognozavimas – optimizuoti elektros gamybą hidroelektrinėse.

Reikiama informacija gaunama iš išorės arba yra generuojama UES valdymo proceso metu. Valdymo procese didžiausi informacijos kiekiai generuojami ir panaudojami elektros gamybos, perdavimo ir skirstymo proceso tempu. Skirtingi valdomi procesai kinta įvairiai: atitinkamai greitai, nepakankamai greitai ir lėtai, skirsis kontrolės veiksmų įgyvendinimo vėlavimai, skirsis ir informacijos gavimo bei panaudojimo laikas.

Telemechanikos teikiama informacija vadinama telemechaninis. Panagrinėkime apytikslius priimtinus jo delsos diapazonus perduodant iš valdymo objektų į valdymo centrą ( kontrolė informacija) ir atgal ( komanda informacija):

· informacija automatinėms avarinėms sistemoms (tele-išjungimas) – dešimtys milisekundžių;

· jungiklių ir skyriklių padėties telesignalizacija – sekundės;

· valdomų parametrų (momentinių reikšmių) telemetrija – vienetai ir dešimtys sekundžių;

· telemetrija, teleskaičiavimas (integralinės reikšmės) – keliasdešimt sekundžių;

· automatinio valdymo sistemų telemetrija ir telekomandos - iki 1 s;

· nuotolinis valdymas (TC) – kelios sekundės;

· atsakomasis telesignalavimas (po techninių specifikacijų) - iki 10 s;

· tarp lygių mašinų mainai tarp kompiuterinės informacijos duomenų bazių OIUC – kelios minutės;

· energijos gamybos ir vartojimo išsiuntimo sąrašas – 1 kartas per valandą.

Telemechaninės informacijos kokybę lemia visų į informacijos perdavimo grandinę įtrauktų įrenginių paklaida (tikslumo klasė) ir ji svyruoja nuo procento dalies iki kelių procentų.

Be to, televizijos transliacijų vėlavimas turi didelės įtakos televizijos informacijos kokybei. Norint sumažinti šį vėlavimą, būtina didinti matavimų dažnumą ir informacijos perdavimo greitį, todėl reikia plėsti ryšio kanalus ir didinti jų savikainą. Norint naudoti esamus ryšio kanalus jų neplečiant, reikia naudoti informacijos suspaudimo būdus, adaptyvius pranešimų perdavimo algoritmus, prioritetinę sistemą ir kt.

Siųsti savo gerą darbą žinių bazėje yra paprasta. Naudokite žemiau esančią formą

Studentai, magistrantai, jaunieji mokslininkai, kurie naudojasi žinių baze savo studijose ir darbe, bus jums labai dėkingi.

Paskelbta http://www.allbest.ru/

[Įveskite tekstą]

Įvadas

Taksi dispečerinės tarnybos IS kūrimas vykdomas pagal sudaryto taksi dispečerinės tarnybos katalogo pavyzdį. Kataloge bus rodomi automobiliai, jų vairuotojai, klientai, užsakymų datos, užsakymo įvykdymas, užsakymo kaina, užsakymų adresai.

1. Dalyko sritis

Nagrinėjama taksi paslaugų dispečerių veikla, kuri privalo:

Tvarkykite klientų sąrašą, kuriame įvedate kortelės numerį, vardą ir pavardę, namų adresą ir mobiliojo telefono numerį.

Automobilių sąrašas, kuriame įvedate automobilio numerį, automobilio markę, automobilio valstybinį numerį, automobilio vairuotoją.

Užsakymų sąrašas, kuriame įrašomas užsakymo kodas, užsakymo data, automobilio numeris, kortelės numeris, užsakymo suma, užsakymo būsena.

Vairuotojų sąrašas, kuriame įrašoma vairuotojo pavardė, vardas ir stažas.

2. Problemos formulavimas

Proceso modelių kūrimą iliustruoja Taksi dispečerinės tarnybos duomenų bazės kūrimo pavyzdys.

Sistemos elementų modeliavimas.

IDEF0 diagramos

DFD diagramos

3. Koncepciniai reikalavimai

Duomenų bazės projektavimui pasirinktas universalaus projektavimo metodas ER metodas (esybės-ryšio metodas). Naudojant šį metodą, visų pirma būtina sukurti ER modelį, atspindintį tam tikros dalykinės srities subjektų ryšius. Toliau, remiantis ER diagrama, kuriamos duomenų bazės.

Subjektai – tai konceptualūs reikalavimai, į kuriuos būtina atsižvelgti kuriant duomenų bazę: klientų, užsakymų, automobilių, vairuotojų katalogus.

Normalizavimas

Norint sukurti duomenų bazę, būtina atskleisti konceptualių reikalavimų esmę ir juos normalizuoti. Lentelės normalizavimas yra nuoseklus lentelės struktūros keitimas, kol ji atitinka paskutinės normalizavimo formos reikalavimus.

Aš normalios formos

Lentelė yra pirmosios normalios formos tada ir tik tada, kai nė viename lauke nėra daugiau nei vienos reikšmės ir bet kuris raktas.laukas nėra tuščias.

Atskleidžiame konceptualių reikalavimų esmę:

Automobiliai (automobilio numeris, automobilio markė, valstybinis automobilio numeris, vairuotojas).

Klientas (kortelės numeris, pavardė, vardas, namų adresas, telefono numeris).

Užsakymas (užsakymo kodas, užsakymo data, užsakymo laikas, automobilio numeris, kortelės numeris, užsakymo suma, užsakymo būsena).

Vairuotojas (Pavardė, vardas, stažas).

II normali forma

Lentelė yra antrosios normaliosios formos, jei ji atitinka pirmosios normaliosios formos reikalavimus ir visi jos laukai, kurie nėra įtraukti į pirminį raktą, turi visišką funkcinę priklausomybę nuo pirminio rakto:

1 lentelė – automobilis

2 lentelė – Užsakymai

3 lentelė – Klientai

III normali forma

Lentelė yra trečiosios normaliosios formos, jei ji atitinka antrosios normaliosios formos reikalavimus ir nė vienas jos neparaktinis laukas funkciškai nepriklauso nuo jokio kito neparakto lauko:

3 paveikslas – automobilio stalas

4 pav. Užsakymų lentelė

5 pav. Klientų lentelė

6 pav. Vairuotojo stalas

4. Struktūrinė schema

Remdamiesi trečiąja normalia forma, sukuriame Taksi dispečerinės tarnybos duomenų bazės struktūrinę schemą.

Duomenų bazės struktūrinės schemos kūrimas.

Įveskite duomenų schemą: Skirtukas Darbas su duomenų bazėmis.

Įrankių juostoje spustelėkite „Duomenų schema“.

7 pav

Langas su lentelių sąrašu

Dukart spustelėkite lentelės pavadinimą, kad įtrauktumėte lenteles į lauką

8 pav

Nustatykite ryšį tarp lentelių

9 pav

5. Darbo tvarka

Pirmiausia sukurkime duomenų bazę spustelėdami „Failas – Naujas – Nauja duomenų bazė“. Nustatykite duomenų bazės pavadinimą, išsaugokite vietą ir spustelėkite Sukurti.

10 pav

Dabar nustatome lentelės struktūrą.

Skirtuke Pagrindinis pasirinkite režimą „Dizainas“.

11 pav

Išsaugokite lentelę pasirinktu pavadinimu.

12 pav

Sukurkite lentelę dizainerio lange.

13 pav

6. Lentelių kūrimas dizaino rodinyje

Spustelėkite „Sukurti lentelę projektavimo režimu“.

Įveskite lauko pavadinimą.

Pasirinkite duomenų tipą.

Pirminį raktą nustatykite paspausdami įrankių juostoje esantį mygtuką „Raktas“, užvedę žymeklį į lauką, esantį kairėje nuo norimo pavadinimo (laukų sąraše rakto laukas turi būti pirmoje vietoje).

Įvedę visus reikiamus laukus ir jų tipus, nustatykite uždarymo lentelės pavadinimą.

Stalai statomi panašiai:

Automobilis.

Vairuotojas.

Santykio tarp lentelių kūrimas.

Norėdami atidaryti duomenų schemą, įrankių juostoje spustelėkite piktogramą „Duomenų schema“.

Atsidariusiame papildomame lange „Pridėti lenteles“ spustelėkite reikiamus lentelių pavadinimus ir spustelėkite mygtuką „Pridėti“.

Pagrindinių lentelių laukų sujungimas: spustelėdami pelę pasirinkite lauką vienoje iš lentelių, kurios bus sujungtos to paties pavadinimo lauke kitoje lentelėje, ir, laikydami nuspaudę pelę, vilkite šį lauką į lauką, kurį norite sujungti . Atleiskite pelę ir atsidarys langas „Keisti ryšius“, nurodantis atitinkamų jungiamų lentelių laukus ir šių laukų prijungimo tipą: „vienas su vienu“, „vienas su daugeliu“:

Jei ryšio tipas yra „vienas su vienu“, pažymėkite duomenų vientisumo žymimąjį laukelį ir spustelėkite Gerai.

Su bendravimo „vienas su daugeliu“ tipu.

Duomenų vientisumo užtikrinimas.

Kaskadinis susijusių laukų atnaujinimas.

Pakopinis susijusių laukų trynimas.

Spustelėkite Gerai.

Dėl to turime Taksi dispečerinės tarnybos duomenų bazės lentelių jungčių schemą.

7. Formų kūrimas

Eikite į skirtuką Kurti. Viršutiniame skydelyje spustelėkite mygtuką „Forma“. Sukuriama užpildyti forma. Išsaugokite formą pavadinimu „Įvesties forma“. Sutaupyti. Dešiniuoju pelės mygtuku spustelėkite formos pavadinimą ir pasirinkite „Formos režimas“. Arba skirtuke „Kūrimas“ pasirinkite „Formos vedlys“:

8. Užklausų kūrimas

taksi duomenų bazės konstruktorius

Prašymų tipai:

Paprasta užklausa – užklausos kūrimas iš konkrečių laukų.

Kryžminė užklausa – sukurkite užklausą, kurioje duomenys būtų rodomi kompaktišku formatu, panašiu į skaičiuoklę.

Pasikartojantys įrašai – sukurkite užklausą, kad paprastoje lentelėje ar užklausoje rastumėte pasikartojančius įrašus.

Nepavaldyti įrašai – sukurkite užklausą, kad surastumėte įrašus, kurie neatitinka jokių pavaldžios lentelės įrašų.

Paprastas prašymas

Skirtuko Kurti grupėje Užklausos spustelėkite Užklausų vedlys.

14 pav

Dialogo lange Nauja užklausa pasirinkite parinktį Paprasta užklausa ir spustelėkite Gerai.

15 pav

16 pav

Grupėje Lentelės ir užklausos pasirinkite lentelę, kurioje yra reikalingi duomenys. Atminkite, kad kaip duomenų šaltinį galite naudoti kitą užklausą. Pasirinkus lentelę, jos laukai rodomi srityje Galimi laukai.

9. Kirstiprašymas

Skirtuko Kurti grupėje Kita spustelėkite Užklausų kūrimo priemonė.

17 pav

Dialogo lange Pridėti lentelę dukart spustelėkite kiekvieną lentelę arba užklausą, kurią norite naudoti kaip įrašų šaltinį.

Pridėkite norimus naudoti laukus į sąrašą Pasirinkti laukai, tada spustelėkite Pirmyn. Dabar turėtumėte nustatyti grupavimo kriterijus, naudojamus skirstant eilutes į stulpelius

Pridėkite norimus naudoti laukus į sąrašą Pasirinkti laukai, tada spustelėkite Pirmyn. Dabar turite nustatyti grupavimo kriterijus, naudojamus skirstant eilutes į stulpelius. Šiuo metu galite pasirinkti vieną lauką.

Pasirinkite lauką stulpelių grupavimui ir spustelėkite Pirmyn. Paskutinis veiksmas yra pasirinkti skaičiavimą, kurį norite atlikti, kad gautumėte rezultatus. Pasirinkite lauką, kurį norite apskaičiuoti, o tada – funkciją, skirtą suvestiniams duomenims apskaičiuoti.

10. Ataskaitų generavimas

Norėdami sukurti ataskaitą, turite eiti į skirtuką „Kūrimas“ ir pasirinkti „Ataskaita“.

Ataskaitas galima kurti naudojant:

Ataskaitų dizaineris.

Pranešimų vedliai.

Ir rankiniu būdu.

Mūsų duomenų bazėje ataskaita sukuriama naudojant ataskaitų vedlį. Turite spustelėti „Pranešimo vedlys“. Atsidarys langas.

18 pav

Turimus laukus perkeliame po vieną, paspaudę mygtuką „>“.

Norėdami perkelti visus laukus iš karto, spustelėkite mygtuką „>>“.

19 pav

Kitame lange galite paskirstyti grupavimo lygius.

Kitame veiksme galite pasirinkti ataskaitos išdėstymo tipą, taip pat pasirinkti vertikalią arba gulsčią orientaciją.

Prie ataskaitos galite priklijuoti lipdukus. Taip pat galite sukurti tuščią ataskaitą.

Duomenų bazės kūrimo pabaigoje turėtų būti sukurta bendra ataskaita, kurioje būtų visi laukai.

Išvada

Taksi dispečerinės tarnybos proceso modelio kūrimas atliktas taksi dispečerinės tarnybos katalogo sudarymo pavyzdžiu.

Taksi dispečerinės tarnybos kataloge pateikiami jų vairuotojų, klientų automobiliai, užsakymų datos, užsakymų įvykdymas, užsakymo kaina, užsakymų adresai.

Literatūra

1. Gvozdeva V.A., Lavrentieva I.Yu., Automatizuotų informacinių sistemų kūrimo pagrindai - Maskva, Leidyklos forumas - INFRA - M, 2007. - 320 p.

2. Fufajevas D.E., Fufajevas D.E. Automatizuotų informacinių sistemų kūrimas ir eksploatavimas - Maskva, Akademijos leidybos centras, 2010. - 304 p.

3. Gagarina L.G., Kiselevas D.V., E.L. Fedotova. Automatizuotų informacinių sistemų kūrimas ir eksploatavimas - Maskva, Leidyklos forumas - INFRA - M, 2009. -384p.

4. Dimovas Yu.V. Metrologija, standartizavimas ir sertifikavimas – Petras, 2005 m

5. Pirogovas V.Yu. Informacinės sistemos ir duomenų bazės: organizavimas ir projektavimas: vadovėlis. Vadovas - SPB.BVH- Sankt Peterburgas, 2009. -528 p.

6. Kharitonova I.A., Mikheeva V.D. MicrosoftAccess 2000 – Sankt Peterburgas. : BVH-Peterburgas, 1999. - 1088 p.

7. Maksimovas N.V. ir kt.. Šiuolaikinės informacinės technologijos. Vadovėlis-M: „FORUMAS“: INFRA-M, 2011 m.

Paskelbta Allbest.ru

Panašūs dokumentai

    Duomenų bazės lentelių kūrimas projektavimo režimu. Lentelių ir lentelės turinio jungčių schema. Ryšio užmezgimas išlaikant vientisumą. Dviejų užklausų struktūros (projektavimo režimu) ir jų kūrimo proceso aprašymas. Pranešti apie išvesties rezultatus.

    kursinis darbas, pridėtas 2015-06-28

    „Access“ duomenų bazės pagrindinių komponentų sampratos. Lentelės, ataskaitos, makrokomandos ir moduliai, formos, užklausos į duomenų bazę ir jų tipai. Duomenų tipai. „Personalo“ duomenų bazės sukūrimas. Lentelės kūrimas projektavimo režimu. Peržvalgos vedlio naudojimas ryšiams kurti.

    kursinis darbas, pridėtas 2016-10-03

    Sukurkite duomenų bazę „Microsoft Access“ naudodami šablonų vedlį. Kurkite lenteles įvesdami duomenis naudodami lentelių vedlį arba lentelę lentelių projektavimo režimu. Kurkite užklausas „Microsoft Access“ naudodami vedlį arba užklausų dizainerį.

    santrauka, pridėta 2010-09-08

    Duomenų bazių lentelių kūrimas naudojant MS Access „Azijos šalys“. Duomenų bazės forma ir užklausos duomenų pavyzdžiams. Lentelių struktūros keitimas, ryšių tarp pagrindinių lentelių kūrimas, duomenų redagavimas ir formų projektavimas realiai duomenų bazei.

    testas, pridėtas 2012-11-25

    Duomenų bazės lentelių kūrimas projektavimo režimu. „Bibliotekos“ duomenų bazės lentelių pavadinimas ir struktūra. Peržvalgos lauko taikymas ir fiksuoto laukų reikšmių sąrašo sukūrimas. Sujungimų tarp lentelių schema. Prašymo formavimas ir vykdymas.

    testas, pridėtas 2009-07-24

    Duomenų bazių lentelių normalizavimo samprata ir jos paskirtis. Normalizavimo proceso etapai. Nenormalizuotų duomenų pavyzdys. Įprastos formos, iki kurių sumažinamos lentelės. Reliacinė algebra virš ugdymo pagrindo. Duomenų bazė dalykinei sričiai „Pamokos“.

    testas, pridėtas 2010-07-30

    Magistrantūros studijų programos dekanato duomenų bazės, apimančios informaciją apie studentus, studijų formas, egzaminus, kūrimas. Lentelių ir užklausų kūrimas projektavimo režimu, ataskaitų kūrimas naudojant ataskaitų vedlį. Duomenų išvedimas naudojant formas. Mygtukų skirtukai.

    kursinis darbas, pridėtas 2014-07-18

    Knygyno veiklos automatizavimas. Duomenų bazės informacija. Lentelių „Knygos“, „Pirkėjas“, „Tiekėjas“, „Darbuotojai“ laukelių užpildymas. Sukurkite užklausą dizaino režimu. Duomenų išvedimas naudojant formas. MS Access DBVS taikomosios programos kūrimas.

    kursinis darbas, pridėtas 2015-01-13

    Duomenų bazės kūrimas, plėtros planavimas ir sistemos reikalavimai. Duomenų bazės projektavimas programoje Microsoft Access, elementai ir duomenų tipai. Sukurkite lenteles ir pasitelkite dizainerį jas modernizuoti. Užklausų kūrimas ir makrokomandų kūrimas.

    kursinis darbas, pridėtas 2011-04-16

    Programų, leidžiančių kurti duomenų bazes, kūrimas. Duomenų bazės lentelės kūrimas. Duomenų schemos kūrimas. Formų, ataskaitų, užklausų kūrimas. Didėjantis saugomų duomenų kiekis ir struktūrinis sudėtingumas. Access duomenų bazių valdymo sistemos charakteristikos.

UDC 614.8:351.86+519.8

Avarinių operatyvinių tarnybų budinčių ir dispečerinių tarnybų informacinės sąveikos organizavimo problemos kuriant sistemą-112

V. N. Zubkovas, S. V. Agejevas, O. V. Denisovas, V. V. Tyminskis, A. S. Akulšinas Santrauka

Straipsnyje pateikiamos pagrindinės pagalbos tarnybų informacinių sistemų kūrimo ir veikimo problemos.

Raktažodžiai: Sistema-112, pagalbos skambutis, vieninga savivaldybės budinčio dispečerinio tarnyba, sprendimų palaikymas, automatizuotos priemonės.

Avarinio lauko tarnybų organizacijos informacinės sąveikos problemos kuriant sistemas-112

V. Zubkovas, S. Agejevas, O. Denisovas, V. Tyminskis, A. Akulšinas, Abstract Abstract

Straipsnyje pateikiamos pagrindinės pagalbos lauko tarnybų informacinių sistemų kūrimo ir veikimo problemos.

Raktažodžiai: Sistema-112, pagalbos iškvietimas, vieninga savivaldybės administracijos dispečerinė, sprendimų palaikymas, automatizuotos priemonės.

Dar gerokai prieš sumanymą sukurti System-112 Rusijoje atsirado ir iki šiol egzistuoja įvairios tarnybos, kurios priima visuomenės skambučius apie įvairius incidentus ir organizuoja reagavimą į juos. Šiuo atveju pareiškėjas pats kvalifikuoja probleminį įvykį, dėl kurio nori gauti pagalbą pagal jam žinomą operatyvinės tarnybos kompetenciją ir pasirenka, kuriai avarinei tarnybai spręsti jo problemą, vienu iš specializuotų paslaugų numerių (01, 02, 03). , 04 ir kt.). Paprastai tai nesukelia jokių sunkumų. Susisiekimo atvejai „netinkamu adresu“ nėra sisteminiai, o jų skaičius neviršija įprasto

daug melagingų pranešimų, kuriuos gavo šios tarnybos.

Tais atvejais, kai reikalingas integruotas kelių operatyvinių tarnybų pajėgų ir priemonių panaudojimas, įvairūs bendri įsakymai, instrukcijos, nuostatai ir susitarimai organizuoja gana efektyvią sąveiką per budinčias (dispečerines) tarnybas.

Siekdami optimizuoti dispečerinio personalo darbą priimant, apdorojant, registruojant pranešimus ir organizuojant operatyvų reagavimą į juos, padaliniai sukūrė ir efektyviai taiko įvairius algoritmus ir taisykles. Šiuolaikinėmis sąlygomis

Beveik visur pranešimų ir jėgų veiksmų bei priemonių į juos reaguoti registravimas, taip pat atsakymo rezultatų fiksavimas vykdomas elektronine forma (nuo paprastų formų Word ar Excel formatu iki tam tikrų sukurtų „programų“, kaip taisyklė). , vietos departamento specialistai). Visavertėms dispečerinėms sistemoms kurti visada reikia aukšto lygio informacinių technologijų srities įvairių sričių specialistų, todėl tokių sistemų šiandien iš tiesų yra nedaug. Tuo pačiu metu net ir vieno skyriaus rėmuose nėra vieningo požiūrio, todėl skirtingi padaliniai teritorijose aprūpinami skirtingomis skirtingų kūrėjų sistemomis, skirtingu funkcionalumo lygiu ir skirtingu automatizavimo laipsniu. Tai stebina, nes visų nagrinėjamų skyrių padalinių struktūra yra griežtai centralizuota nuo federalinio iki savivaldybių lygmenų, visi skyriai turi šių skyrių patvirtintus algoritmus ir taisykles, skirtas pranešimų priėmimui, apdorojimui, atsakymų į juos organizavimui, rezultatų registravimui. ir statistika, kuri yra vienoda visiems šio skyriaus padaliniams visuose dalykuose.

Pažymėtina, kad Rusijos ekstremalių situacijų ministerijos ir Rusijos vidaus reikalų ministerijos dėjo ir deda pastangas kurdamos operacines dispečerines funkcijas automatizuojančias sistemas ir kompleksus, tačiau šiuose padaliniuose centralizuotai kuriamos ir diegiamos sistemos yra daugiau. informacinio-nuorodinio ir apskaitos-statistinio pobūdžio nei operatyvinis išsiuntimas ir vadovas.

Pažymėtina, kad pranešimų priėmimo, apdorojimo, įrašymo, reagavimo į juos organizavimo jėgomis ir priemonėmis, atsižvelgiant į reagavimo (situacijų sprendimo) rezultatus, algoritmai ir taisyklės iš esmės nesiskiria visose avarinėse operatyvinėse tarnybose. Šią išvadą taip pat galima patvirtinti supratus bet kokių tarnybų veiksmų chronologiją atsakant į pranešimą apie incidentą, kuris priklauso jų kompetencijai:

a) pranešimų gavimas, apdorojimas ir įrašymas;

b) atsakymo į pranešimą organizavimas – pranešimo išsiuntimas tarnyboms (skyriams, pareigūnams), kompetentingoms juos išspręsti;

c) atsakomųjų veiksmų kontrolė (sekimas), įvairių dalyvių, tiesiogiai reaguojančių į pavaldžias pajėgas ir priemones, veiksmų koordinavimas;

d) informacinė pagalba priimant sprendimus (jei reikia) atsakymo dalyviams;

e) tarpinių ir galutinių rezultatų registravimas; statistinių ataskaitų generavimas, įvykių duomenų bazės tvarkymas.

Tai rodo, kad galima sukurti vieningą programinės ir techninės įrangos kompleksą, kuris automatizuotų šį procesą tais pačiais principais visose pagalbos tarnybose arba bet kurioje iš jų.

Įvairiose Rusijos Federacijos ministerijose ir departamentuose naudojamų sistemų, kurios automatizuoja operatyvinės siuntimo kontrolės procesą, analizė,

Iki šiol nenustačiau jokios automatizuotos sistemos, kuri didesniu ar mažesniu mastu apjungtų įvairius operatyvinių tarnybų budėjimus ir dispečerinius padalinius vienoje organizacinėje, programinėje ir techninėje platformoje, bendrais valdymo principais. Toks požiūris labai apsunkina budinčių padalinių sąveikos organizavimą skyriuje, o dar labiau su kitų padalinių DDS.

Atsiradus „System-112“ sukūrimo idėjai (koncepcijai), atsirado galimybė sukurti programinę, techninę ir informacinę platformą, kuri apjungtų visas avarinių operatyvinių tarnybų DDS (ir galbūt ne tik avarines) į vieną informaciją. erdvę (ar net „e. pagalbos“ bendruomenę – elektronines pagalbos tarnybas), kad gyventojams būtų patogu „vieno langelio“ principu skambinti greitosios pagalbos tarnyboms ir organizuoti priemonių kompleksą, užtikrinantį pagreitintą reagavimą ir tobulinimą. operatyvinių tarnybų sąveika priimant gyventojų skambučius (pranešimus apie incidentus). Vieningas „System-112“ programinės ir techninės įrangos kompleksas galėtų tapti programine baze (moduliu), skirta organizuoti informacinę sąveiką tarp operatyvinių tarnybų DDS Rusijos Federaciją sudarančiose dalyse.

Taigi „System-112“ gali tapti subjekto integruotos operatyvinės dispečerinės valdymo sistemos (OSODU) informacijos ir ryšių platforma.

Tačiau pirmiausia, remiantis Koncepcijoje Sistemai-112 priskirtomis užduotimis ir funkcijomis, reikia suprasti, kas yra Sistema-112: informacija (informavimas), išsiuntimas, valdymo sistema ar viskas kartu, o tada nustatyti vaidmenį ir vietą. šios sistemos tarp kitų dalyko sistemų, įgyvendinančių panašias ir susijusias užduotis bei funkcijas.

Sistema, kuri gauna ir apdoroja pranešimus (informaciją) iš pareiškėjo, pagal GOST apibrėžimą, yra informacinė ir jai nereikia šio fakto patvirtinimo ar įrodymų. Taip pat Koncepcijoje aiškiai išskirtos valdymo patalpos tarp Sistemos-112 užduočių – gauti pranešimus ir perduoti informaciją apie įvykį DDS pagal jų kompetenciją organizuoti reagavimą į avariją; visų gaunamų ir siunčiamų pranešimų registravimas ir dokumentavimas, pranešimų statistinių ataskaitų generavimas. Iš Koncepcijos apibrėžimų matyti, kad Sistema-112 pagal jai priskirtas užduotis yra operatyvi dispečerinė sistema.

Koks yra operatyvinės dispečerinės Sistemos-112 vaidmuo ir vieta bendroje subjekto padalinių ir tarnybų, įgyvendinančių panašias operatyvinės dispečerinės funkcijas pagal kompetenciją ir suteiktus įgaliojimus, struktūroje?

Koncepcijoje Sistema-112 apibrėžiama kaip geografiškai paskirstyta informacinė sistema, skirta savivaldybių vieningų budinčių dispečerinių tarnybų (EDDS) pagrindu vienyti skubios pagalbos dispečerines tarnybas.

nacionalinės operatyvinės tarnybos (gaisrinė tarnyba; reagavimo į avarijas tarnyba; policijos tarnyba; greitosios medicinos pagalbos tarnyba; avarinė dujų tinklo tarnyba; antiteroristinė tarnyba).

„112“ operatorių veiksmų algoritmo aprašymas apima valdymo funkcijas, taip pat numato valdymo vertikalę; todėl galime manyti, kad System-112 yra informacijos valdymo sistema.

Dauguma ginčų kyla dėl šio požiūrio susitarimo arba atsisakymo.

Mūsų požiūriu, „System-112“ yra kasdieninio veikimo informacinė sistema, tačiau perjungus į „avarinį“ režimą, ji turi sugebėti perimti valdymo funkciją, kuri apskritai yra įtraukta į koncepciją.

Pagaliau suburti System-112 šalininkų pozicijas, kaip informuoti ir laikyti ją vadovu, bus galima parengus norminį teisės aktą, galbūt pavyzdinį subjekto OSODU reglamentą arba pačią System-112, kuris atspindės ir reglamentuoti EDDS ir kiekvienos skubios pagalbos tarnybos vaidmenį bei vietą. Savo ruožtu suvokus OSODU kaip visumos ir atskirų jos elementų, ypač EDDS, tikslus, uždavinius ir funkcijas, bus galima parengti techninius reikalavimus programinės ir techninės įrangos kompleksui, kuris automatizuoja valdymo procesus ir atskirų sistemos elementų tarpžinybinę sąveiką. .

Remiantis Rusijos Federacijos Vyriausybės patvirtinta Sistemos-112 sukūrimo koncepcija, jos kūrimas turėtų būti grindžiamas savivaldybių EDDS. Todėl vienas iš pagrindinių punktų kuriant System-112 yra EDDS statuso ir teisinės bazės nustatymas.

EDDS, sukurtų Rusijos Federaciją sudarančiose įmonėse, analizė parodė, kad jie paprastai neturi personalo, juo labiau teisinio statuso (savarankiškas juridinis asmuo, organizacija), bet yra tam tikri ne personaliniai padaliniai. administracija. Toks požiūris neįvertina EDDS vaidmens ir vietos reagavimo į ekstremalias situacijas sistemoje, taip pat neleidžia tinkamai organizuoti finansinės paramos šiai tarnybai, taigi ir visai sistemai.

EDDS formų ir metodų analizė parodė, kad racionaliausia EDDS kurti reguliariai kaip savarankišką juridinį asmenį, pavyzdžiui, specialią savivaldybės instituciją, arba kaip gelbėjimo padalinio, kuris taip pat yra neatidėliotinos pagalbos padalinio, dalį. savivaldybės institucija.

Priklausomai nuo regiono administracinio-teritorinio suskirstymo ir gyventojų skaičiaus savivaldybėse, tokias įstaigas galima kurti kiekviename rajone arba po vieną visam dalykui su filialų tinklu kituose rajonuose.

Šis požiūris, mūsų nuomone, leis išspręsti tiek organizacinio pobūdžio problemas kuriant System-112, tiek ateityje išspręsti

Taip pat vienas esminių punktų kuriant Sistemą-112 yra regiono informacinės ir ryšių (IC) infrastruktūros pasirengimo galimybėms panaudoti modernias informacines technologijas (IT) pagalbos iškvietimo sistemoje. Kaip parodė analizė, ryšio kanalai tarp pagalbos tarnybų daugumoje Rusijos Federacijos regionų buvo sukurti šeštajame dešimtmetyje ir yra fiziškai susidėvėję, todėl periodiškai kyla problemų su ryšio operatoriumi, perduodančiu skambutį pagalbos tarnyboms, o juo labiau. organizuojant informacijos (duomenų) perdavimą, budintys ir dispečeriniai darbuotojai neturi galimybių naudotis šiuolaikinėmis informacinėmis priemonėmis ir technologijomis. Pagal Koncepciją „System-112“ yra daugiafunkcė informacijos ir ryšių teritoriškai paskirstyta sistema, kuri apima išvystyto ir modernaus telekomunikacijų komponento, t.y. pakankamai didelio pralaidumo ir patikimumo šviesolaidinių duomenų perdavimo kanalų sukūrimą, WEB technologijų diegimą duomenų perdavimo sistema ir skambučiai tarp EDDS ir DDS.

Todėl, siekiant atrinkti regionus, kad būtų galima laipsniškai diegti System-112, šiuo metu būtina parengti regionų, įskaitant greitosios pagalbos tarnybų DDS, pasirengimo System-112 diegimui vertinimo metodiką, kuri mūsų nuomone, yra vienas iš Rusijos visuomenėje kuriamos informacinės sistemos komponentų (segmento).

Sistemos-112 dislokavimo ir veikimo bandomuosiuose regionuose analizė parodė, kad, organizuojant informacijos sąveiką tarp žinybinių DDS, svarbiausias yra vieningos budinčios dispečerinės tarnybos gaunamų skambučių (pranešimų apie incidentus) priėmimo ir apdorojimo posistemis. Į šią posistemę įeina skambučių centras (CC).

Skambučių priėmimo ir apdorojimo posistemis arba vadinamasis siuntimo posistemis yra EDDS automatizuotos sistemos (AS) valdymo posistemis.

Šiuo metu tarpžinybinės sąveikos organizavimo požiūriu galimos kelios programinės ir techninės įrangos galimybės šiam posistemiui sukurti.

Pažvelkime į du dažniausiai pasitaikančius variantus.

1 variantas

Greitosios pagalbos tarnybos (01, 02, 03 ir kt.) jau turi savo žinybines dispečerines sistemas.

Tokiu atveju turi būti sukurta speciali programinė įranga (SPO), skirta apdoroti skambučius į skambučių centrą pagal EDDS ir į greitosios pagalbos operatyvinės tarnybos DDS, teritoriškai atitinkančius EDDS. Praktiškai tai gali būti įgyvendinta DDS įdedant nuotolinę kliento darbo stotį su atvirojo kodo programine įranga TsOV EDDS, be padalinio.

Automatizuota darbo vieta pranešimų apie incidentus gavimui arba, geriausiu atveju, specialaus integravimo programinės įrangos modulio kūrimui, užtikrinančiam informacijos sąveiką tarp SPO TsOV EDDS ir specialios pagalbos tarnyboms skirtos DDS programinės įrangos.

Teigiamas šio sprendimo dalykas yra tas, kad sistemos diegimas ir jos įdiegimas DDS vyksta radikaliai nesulaužant esamų padalinių automatizuotų įrankių, kurie praktiškai įrodė savo efektyvumą vartotojams.

Šio metodo trūkumus lemia tiesioginis jo įgyvendinimo būdas. Taigi, pavyzdžiui, įdėdamas papildomą kliento darbo vietą pagalbos tarnybos DDS su atvirojo kodo programine įranga TsOV EDDS, operatorius turės atskirai apdoroti per System-112 liniją ir per padalinio sistemą gautus pranešimus. Kad abiejų sistemų statistika būtų suvienodinta, operatorius turės rankiniu būdu perkelti informaciją iš vienos į kitą, o tai ne tik nepagreitina pranešimų apdorojimo ir atsakymo į juos proceso, bet ir tam tikra prasme pakreipia operatorių į „ sabotuoti“ naująją sistemą, pirmenybę teikdamas darbui, nors ir ne šiuolaikiškam ir mažiau funkcionaliam, bet labiau pažįstamam senajai sistemai. Be to, viena iš System-112 užduočių yra "skubėjimo tarnybų iškvietimo metodo suderinimas su Europos Sąjungos teisės aktais", o pagal Europos reikalavimus operatorius turi turėti vieną automatizuotą darbo vietą (vieną klaviatūrą, pelę ir kt. ..). Integravimo modulių diegimas yra problemiškas dėl kitos priežasties. Paprastas potencialių integracijos objektų DDS skaičiaus apskaičiavimas rodo, kad praktikoje geriausiu atveju reikės integruoti su nuo keturių iki šešių dalyko AS - paslaugos 01, 02, 03, 04, greitojo reagavimo tarnyba ( arba TsUKS), kovos su terorizmu tarnyba. Be to, kiekviename dalyke AS gali skirtis nuo AS toje pačioje paslaugoje kaimyniniame regione. Tai yra, turime daugiau nei 250 potencialių integracijos objektų. Be to, išanalizavus automatizuotų sistemų buvimą ir būklę avarinėse tarnybose, matyti, kad dauguma pagalbos tarnybų neturi jokių dispečerinių programų, netgi daugiau ar mažiau modernių informacinių, nuorodų ar apskaitos bei statistikos sistemų. Todėl integracija sukels sunkumų programinės įrangos lygmeniu. Norėdami sėkmingai susieti sistemas, kūrėjai turi atverti savo kūrimą vieni kitiems, o informacijos saugos specialistai turi dėti papildomas pastangas, kad po integracijos apsaugotų savo tinklus ir informacijos išteklius. Daugelio tarnybų vadovų pareigos, nukreiptos į tam tikrą žinybinę izoliaciją, taip pat nėra palankios efektyviam integracijos darbui. Esant didelėms organizacinėms pastangoms ir neabejotinai didelėms tiek finansinėms, tiek informacinių technologijų srities specialistų resursų išlaidoms, teigiamas įgyvendinto sprendimo efektas visiškai nėra akivaizdus.

2 variantas

Kaip jau minėjome, analizė parodė, kad dažniausiai skyriuose iš viso nėra automatizuotos sistemos, pranešimai dažnai įrašomi į žurnalą, organizuojamas atsakymas, jėgų ir resursų veiksmai derinami telefonu.

Taip pat aukščiau paminėjome pagrindinių pranešimų apie incidentus gavimo, apdorojimo, registravimo, reagavimo į juos organizavimo ir pavaldžių pajėgų bei reagavimo priemonių valdymo algoritmų ir principų vienovę visose operatyvinių tarnybų avarinėse tarnybose, nepaisant jų apimties.

Šiuo atveju racionaliausia yra sukurti tam tikrą vieningą automatizuotą sistemą, kuri automatizuotų operatyvinio išsiuntimo valdymo procesus kiekviename DDS atskirai ir OSODU kaip visumoje, ir pristatyti ją visuose skyriuose. Vieninga sistema turėtų užtikrinti duomenų įvedimo per vieną programą principą tik vieną kartą, duomenys turėtų būti prieinami kitoms programoms jų nekopijuojant. Visi operatoriaus (dispečerio) veiksmai sistemoje turi būti automatiškai registruojami realiu laiku, išsaugant informaciją apie tai, kas ir kada atliko šį veiksmą, kad būtų galima visiškai atstatyti incidentą ir avarinio personalo veiksmus dėl jo, taip pat ir mokymo tikslais. Tikslai.

Įgyvendinant šią užduotį, neišvengiami ir tam tikri sunkumai, susiję, viena vertus, su poreikiu sukurti vieningą kelių tarnybų sistemą, kuri, nepaisant operatyvinės dispečerinės kontrolės principų panašumo, objektyviai vis tiek turi savo specifiką. Kita vertus, subjektyvi, izoliuota vadovų ir specialistų padėtis šiuose padaliniuose ir tarnybose iš esmės nesiskirs nuo pozicijos kuriant integracijos modulius.

Tačiau šiuo variantu teigiami aspektai atrodo akivaizdūs – kiekvienas skyrius gauna specializuotą programinės įrangos produktą, sukurtą pagal susitarimą (arba dalyvaujant) „šio skyriaus užduotims“; tiriamojo krizių valdymo sistema gauna visų DDS, EDDS ir TsUKS programinės platformos vienybę, kuri leidžia įgyvendinti vienodas ir sutartas informacijos mainų taisykles RSChS sistemoje. Be to, atsižvelgiant į aukščiau aptartą System-112 vaidmenį ir vietą dalyko OSOD, patartina sukurti AS pagal šį konkretų projektą.

Kiekvienas variantas turi teisę egzistuoti ir gali būti įgyvendintas viename ar kitame dalyke.

Tačiau, mūsų nuomone, labiau tinka antrasis variantas, kuris pradiniame etape (kuriant vieną AS) yra sudėtingesnis, tačiau vėliau, atkartojant sistemą regionuose, diegimo efektas pašalina problemas, kilusias kuriant. .

Tai, kad Koncepcijoje numatyta Sistema-112 diegti savivaldybės EDDS pagrindu

dariniai, kurie yra subjekto RSChS teritorinio posistemio kasdienio valdymo organai, atrodo teisingi ir labai pateisinami. Šiandien EDDS turi teisėtus įgaliojimus organizuoti ir įgyvendinti kasdienį DDS valdymą, įskaitant avarines operacines tarnybas (apibrėžtas Rusijos Federacijos Vyriausybės dekretu...), tačiau iš tikrųjų nėra jokios techninės galimybės. valdymo pagrindas. Kita vertus, System-112 turi tokią programinę ir techninę bazę. Daugumos užduočių ir funkcijų panašumas leidžia ir savivaldybių EDDS paremtą Sistemą-112 laikyti neatsiejama operatyvinės dispečerinės kontrolės sistemos, pagrįstos RSChS teritorinio posistemio kasdieniais valdymo organais, dalimi, t.y. remiantis EDDS. O visų sąveikaujančių tarnybų, o ne tik EDDS pagrindu veikiančių, DDS operatyvinio išsiuntimo valdymo centralizavimas yra dar vienas argumentas už standartinės vieningos operatyvinės dispečerinės valdymo sistemos automatizuotos subjekto sistemos kūrimą.

Tačiau kartu reikia nepamiršti, kad „System-112“ yra sudėtinga informacinė ir ryšių sistema, kuri turėtų tapti tam tikru kuriamos informacinės visuomenės segmentu, leidžiančiu gyventojams laiku, operatyviai ir kvalifikuotai gauti pagalbą. Ir tai neįmanoma be aukštos kvalifikacijos budinčio ir dispečerinio personalo parengimo ar žmogiškojo kapitalo, išmanančio šiuolaikines informacines technologijas, nesukūrus tinkamos informacinės ir ryšių infrastruktūros regione. Priešingu atveju visos pastangos įdiegti System-112 gali būti sumažintos iki pirktos vadinamosios aparatinės įrangos, ant kurios bus rodoma vis daugiau pristatymų apie System-112, tačiau kuri niekada neveiks reikiamu lygiu.

literatūra

1. Rusijos Federacijos Vyriausybės 2008 m. rugpjūčio 25 d. įsakymas Nr. 1240-r dėl Sistemos-112 sukūrimo koncepcijos patvirtinimo.

2. Rusijos nepaprastųjų situacijų ministerijos 2008 m. gruodžio 15 d. įsakymas Nr. 779 „Dėl Rusijos Federacijos Vyriausybės 2008 m. rugpjūčio 25 d. įsakymo Nr. 1240-r.

3. Ministro 2009 m. spalio 27 d. įsakymas Nr. 379 „Dėl darbo grupės, skirtos skubios pagalbos tarnybų iškvietimo vienu numeriu „112“ sistemos, sukūrimo Rusijos Federacijos savivaldybių EDDS pagrindu.

4. Rusijos nepaprastųjų situacijų ministerijos 2009 m. balandžio 9 d. įsakymas Nr. 224 „Dėl skubios pagalbos tarnybų iškvietimo vienu numeriu „112“ sistemos diegimo ir veikimo metodikos parengimo remiantis 2009 m. Rusijos Federacijos bandomųjų regionų savivaldybių EDDS.

5. Rusijos nepaprastųjų situacijų ministerijos 2009 m. birželio 1 d. įsakymas Nr. 331 „Dėl tarpžinybinės darbo grupės parengti Skambučių į greitosios pagalbos tarnybą teikimo vienu numeriu „112“ sistemos diegimo ir veikimo metodiką. “ remiantis Rusijos Federacijos bandomųjų regionų savivaldybių EDDS.

6. Rusijos Federacijos Vyriausybės 2004 m. gruodžio 31 d. potvarkis Nr. 894 „Dėl skubių operatyvinių tarnybų, į kurias telekomunikacijų operatorius privalo skambinti visą parą ir nemokamai, sąrašo patvirtinimo ir 2004 m. vieno numerio suteikimas greitosios pagalbos tarnyboms iškviesti“.

7. Rusijos nepaprastųjų situacijų ministerijos valdybos 2007 m. rugpjūčio 29 d. sprendimas Nr. 7/1 „Dėl pasirengimo Rusijos Federacijos teritorijoje įdiegti skubios pagalbos tarnybų iškvietimo vienu numeriu sistemą“ 112“.

9. GOST R22. 7.01-99 EDDS. Pagrindinės nuostatos.

Zubkovas Vasilijus Nikolajevičius, Rusijos nepaprastųjų situacijų ministerijos vyriausiasis direktoratas Kursko srityje, vadovas. Agejevas Sergejus Vladimirovičius, mokslų daktaras. Sc., Federalinės valstybinės institucijos Visos Rusijos civilinės gynybos ir ekstremalių situacijų tyrimų instituto (FC) vadovaujantis mokslo darbuotojas. Denisovas Olegas Viačeslavovičius, Federalinės valstybinės institucijos VNII GOChS (FC) centrinis skyrius, vadovas.

Tyminskis Vladimiras Valentinovičius, Rusijos valstybinės institucijos „TsUKS EMERCOM Kursko regionui“ vadovas. Akulšinas Sergejus Borisovičius, valstybinė institucija „TsUKS EMERCOM of Russia Kursko regionui“, specialistas.

mob_info