-
Data: 2010-01-11 15:20:01
Temat: Re: Maskowanie schematów zużycia energii
Od: shortestpath <m...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]> Permanentna inwigilacja :-)
> Nie mow ze nie zyczysz sobie zeby elektrownia wiedziala jak
> pelargonie uprawiasz :-)
>
> J.
Nie uprawiam nic, jednak zastanawiam sie nad czysto teoretycznym
problemem ukrycia faktu zuzycia energii wedlug schematu, ktorego
policja we wspolpracy z dostawcami energii uzywa do namierzania
domowych upraw roslin (nawet jezeli sa to kaktusy to nieoczekiwany
kontakt z wladzami nie jest niczym pozadanym).
Schemat ktory przedstawilem jest oczywiscie przypadkowy, w
rzeczywistosci ten, ktory wzbudzalby podejrzenia, wygladalby tak: 18/6
i potem 12/12.
Podejrzenia wzbudza regularnosc wzrostu zuzycia energii, najczesciej w
czasie nocnej taryfy. W przypadku malego zuzycia (instalacje do 1200W)
wlasciwie nie ma sie co przejmowac, jednak jest to interesujace jako
problem inzynierski.
Przykladowe rozwiazanie to np, wlaczac lampy w cyklu pozornie
chaotycznym, jednak z zachowaniem wymaganego 18/6 lub 12/12 - innymi
slowy manipulowac zuzyciem pradu tak, zeby wygladal na chaotyczny
(symulujac urzadzenia jak np. grzejnik, lodowka, klimatyzacja,
narzedzia, kuchenka), jednak w ramach tego czasu zachowac stabilnosc
cyklu swiecenia/ciemnosci.
Innym rozwiazaniem byloby skonstruowanie elektronicznego wlacznika
czasowego, ktory wlaczalby lampy w cyklu np 16-8, 15-9, 14-10, itd,
losowo dobierajac dana konfiguracje, jednak z zachowaniem minimum 12
godzin swiecenia. Wtedy swiatlo nalezaloby odcinac mechanicznie w
cyklu 12/12 (np za pomoca mechanizmu zaluzji). Rodzi to jednak problem
dodatkowego chlodzenia lampy zamknietej w niewielkiej komorze przy
suficie (miedzy sufitem a zaluzjami), oraz szereg innych - np
szczelnosc swietlna.
Te pomysly wydaja mi sie strzelaniem z armaty do muchy. Sadze, ze
istnieje jakis prosty sposob zrealizowania takiego zamaskowania z
uzyciem elektroniki/elektryki - niestety w tych dziedzinach jestem
ignorantem. Przychodzilo mi do glowy skonstruowanie opornika, grzalki,
lub czegos co zuzywa duzo pradu i jednoczesnie nie generuje wiele
ciepla (jednak zasada zachowania energii sugeruje, ze moze byc to
trudne).
Reasumujac - problem dotyczy skonstruowania mechanizmu pozorowanej
randomizacji cyklicznego wzrostu zyzycia energii elektrycznej celem
ukrycia przed dostawca schematow skokowego wzrostu poboru pradu wedlug
schematu 12/12. (brzmi jak tytul pracy inzynierskiej) :)
Następne wpisy z tego wątku
- 11.01.10 18:29 pluton
- 11.01.10 18:50 shortestpath
- 11.01.10 19:57 Adam Moczulski
- 11.01.10 21:06 J.F.
- 11.01.10 21:52 shortestpath
- 11.01.10 22:57 kogutek
- 11.01.10 23:06 nadir
- 11.01.10 23:31 W.Bicz
- 12.01.10 05:21 bujnos
- 12.01.10 16:27 J.F.
- 12.01.10 21:19 pluton
- 14.01.10 22:51 Robert Tomasik
- 15.01.10 22:54 J.F.
- 15.01.10 23:21 Robert Tomasik
- 16.01.10 19:11 J.F.
Najnowsze wątki z tej grupy
- Zapora Stronie Śląskie cd
- Filtr do pompy ruskiej
- Wyważanie kół rowerowych
- Belka
- Precyzyjne cięcie opony samochodowej
- Nieparzyste dmuchanie
- Klej "samopoziomujący"
- Kocioł CO po raz kolejny
- zapora Stronie Slaskie
- powodz
- Nie atom tylko fotowoltanika i elektroliza
- Test samoodkręcania nakrętek
- Budowlańcy pomóżcie
- wyciskanie/odlewanie hdpe. Co ma sens?
- Pomysł na czujnik przeciążenia siłownika.
Najnowsze wątki
- 2024-12-14 światła znów wlączyli
- 2024-12-14 nie lekceważ termostatu
- 2024-12-14 numer 112
- 2024-12-14 Pendrive, ale dysk
- 2024-12-12 Autocom CAN CDP+ wysokie kody błędów
- 2024-12-13 termostat do lodowki
- 2024-12-13 Gdańsk => Inżynier bezpieczeństwa aplikacji <=
- 2024-12-13 Warszawa => Head of International Freight Forwarding Department <=
- 2024-12-13 Poznań => Employer Branding Specialist <=
- 2024-12-13 Kraków => Business Development Manager - Dział Sieci i Bezpieczeńst
- 2024-12-13 Kraków => Business Development Manager - Network and Network Security
- 2024-12-13 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-12-13 Gdańsk => Programista Full Stack .Net <=
- 2024-12-13 Warszawa => Analityk Biznesowo-Systemowy <=
- 2024-12-13 Białystok => Architekt rozwiązań (doświadczenie w obszarze Java, A