\chapter{Algoritmus ��zen�}
�kolem v~t�to pr�ci bylo navrhnout algoritmus vyjedn�v�n� mezi jednotliv�mi k�i�ovatkami tak, aby koordinovanou zm�nou sv�ch offset� vytvo�ili zelenou vlnu a~tedy aby projelo co nejv�ce vozidel bez zbyte�n�ho zastavov�n�. V t�to kapitole bude takov�to algoritmus p�edstaven a n�sledn� bude pops�na jeho implementace do ji� funguj�c�ho simula�n�ho prost�ed�.
\section{N�vrh algoritmu}
\label{sec:navrh}

Navr�en� strategie ��zen� se skl�d� z~agent�, kte�� jsou p�i�azeni k~jednotliv�m k�i�ovatk�m. Ka�d� agent m��e ovl�dat offset sign�ln�ho pl�nu u~sv�ho �adi�e k�i�ovatky, od n�j naopak z�sk�v� �daje z~detektor�  popisuj�c� aktu�ln� stav provozu. Nav�c soused�c� agenti mezi sebou mohou komunikovat. Toho vyu��vaj� p�edev��m k~tomu, aby zjistili nastaven� offsetu na vedlej��ch k�i�ovatk�ch, respektive p�esn�ji aby v�d�li kdy mohou od soused� o�ek�vat p��jezd vozidel. Ze z�skan�ch informac� pak agent usoud�, jestli by zm�na sousedova offsetu nemohla p�in�st zlep�en� situace a~pokud ano, pokus� se tuto zm�nu vyjednat.

Jedn�m z~nosn�ch prvk� n�vrhu je funkce, kter� ohodnot� konkr�tn� nastaven� offsetu a~umo�n� tak tedy porovnat r�zn� jeho hodnoty a~vybrat tu mo�n� nejlep��. Za tuto m�ru kvality byl zvolen odhad po�tu aut, kter� projedou k�i�ovatkou bez zastaven�. 
Do v�po�tu jsou zahrnuta jen vozidla ze sm�r� od jin�ch ��zen�ch k�i�ovatek.

Pro v�po�et hodnocen� (v~programu naz�van�m \texttt{rating}) je t�eba pro ka�d� j�zdn� pruh na vjezdech do k�i�ovatky zn�t d�lku fronty a~o�ek�van� �asy p��jezd� vozidel od sousedn� k�i�ovatky. D�lka fronty se �e�� pozd�ji, p��jezdy agent pak z�sk�v� p��mo od souseda. Ten je po��t� podle vztahu
\begin{equation}
	t_\mathrm{z} = t_{\mathrm{zz}} + \frac{d}{v_\mathrm{P}} + \mathit{offset}
	\label{eq:tz}
\end{equation}
a~\begin{equation}
	t_\mathrm{k} = t_\mathrm{z} + t_{\mathrm{dz}} \;,
	\label{eq:tk}
\end{equation}
kde $t_\mathrm{z}$ je �as za��tku p��jezdu aut a~$t_\mathrm{k}$ �as konce. D�le pak $t_{\mathrm{zz}}$ je �as za��tku sv�cen� zelen�, $d$ vzd�lenost ke k�i�ovatce, kter� ��d� o~�asy p��jezd�, $v_P$ pr�m�rn� rychlost vozidel, $\mathit{offset}$ nastaven� offset a~$t_{\mathrm{dz}}$ d�lka sv�cen� zeln�. K~t�mto dv�ma vypo��tan�m hodnot�m se je�t� p�id�v� p�edpokl�dan� po�et aut. Jeho odhad je z�sk�n z~hustoty provozu v~minul�m cyklu. K�i�ovatka zas�laj�c� odhady takov�chto trojic �daj� p�ed�v� n�kolik -- podle toho, kolik f�z� rozsv�c� zelenou ve sm�ru p�ipou�t�j�c�m j�zdu k~sousedovi ��daj�c�mu o~odhady.

\begin{figure}%
	\centering
	\includegraphics[width=\columnwidth]{expand}%
	\caption{Periodick� prodlou�en� intervalu sv�cen� zelen�: Mod�e jsou ozna�eny intervaly, kdy p�ij�d�j� vozidla, zelen� interval, kdy dle sign�ln�ho pl�nu sv�t� zelen� (se zapo��t�n�m offsetu). Horn� obr�zek potom p�edstavuje stav p�ed prodlou�en�m, doln� po n�m.}%
	\label{fig:expand}%
\end{figure}

Hodnocen� je pak tedy po��t�no po jednotliv�ch j�zdn�ch pruz�ch. Pro ka�d� je nutn� prov�st periodick� prodlou�en� �asu sv�cen� zelen� odpov�daj�c� sign�ln� skupiny tak, aby v ka�d�m okam�iku intervalu od �asu $0$ po �as posledn�ho p�edpov�zen�ho p��jezdu vozidel bylo jasn�, jak� znak bude v tomto j�zdn�m pruhu signalizov�n. Tento interval je d�le zna�en $T$. Princip periodcik�ho prodlou�en� je p�edstaven na obr�zku \ref{fig:expand}.

Interval $T$ pot� rozd�l�me na posloupnost interval� $\left(T_i\right)^{k}_{i=1}$. $T_i$ jsou intervaly typu $\left<a_i;b_i\right>$, kde $b_i=a_{i+1}$ $\forall i \in \left\{ 1, \ldots, k-1\right\}$, $a_1$ a~$b_k$ jsou krajn� body intervalu $T$ a~$a_i$ jsou chronologicky �azen� v�echny \emph{v�znamn� body}, T�mi se rozum� body, ve kter�ch se m�n� signalizovan� znak nebo ve kter�ch za��n� �i kon�� p��jezd vozidel od souseda. Ka�d� interval $T_i$ lze t�m p�dem rozd�lit na �ty�i druhy, podle toho jestli v n�m p�ij�d�j� nebo nep�ij�d�j� vozidla a jestli sv�t� nebo nesv�t� zelen�. �ekneme, �e $T_i$ je
\begin{enumerate}[(i)]
	\item typu 1 $\iff$ v jeho pr�b�hu p�ij�d�j� auta do fronty a sv�t� zelen�
	\item typu 2 $\iff$ v jeho pr�b�hu p�ij�d�j� auta do fronty a nesv�t� zelen�
	\item typu 3 $\iff$ v jeho pr�b�hu nep�ij�d�j� auta do fronty a sv�t� zelen�
	\item typu 4 $\iff$ v jeho pr�b�hu nep�ij�d�j� auta do fronty a nesv�t� zelen�
\end{enumerate}

Pomoc� tohoto d�len� pak po��t�me d�lku virtu�ln� fronty na konci interval� $T_i$ n�sleduj�c�m zp�sobem:
\begin{equation}
	Q_V^{(i)} = Q_V^{(i-1)} + u(T_i)\,,
	\label{eq:qk}
\end{equation}

kde $Q_V^{(i)}$ je d�lka virtu�ln� fronty na konci $i$-t�ho intervalu. Funkci $u(T_i)$ je definov�na takto: \mbox{$u:\left<a;b\right> \rightarrow \mathbb{R}$}
\begin{equation}
	u(T_i)=
	\begin{cases}
		|T_i|\cdot (c_o-\rho_i)	&\text{pokud } T_i \text{ je typu 1}  \\
		|T_i|\cdot \rho_i				&\text{pokud } T_i \text{ je typu 2}  \\
		-|T_i|\cdot c_o 				&\text{pokud } T_i \text{ je typu 3}  \\
		0												&\text{pokud } T_i \text{ je typu 4} 
	\end{cases}
	\;.
	\label{eq:uti}
\end{equation}

kde $|T_i|$ je d�lka intervalu $T_i$, $\rho_i$ hustota p�ij�d�j�c�ch vozidel b�hem intervalu $T_i$ a~$c_o$ je empiricky zji�t�n� konstanta -- po�et vozidel, kter� za sekundu opust� k�i�ovatku (tedy vlastn� hustota odj�d�j�c�ch vozidel).

Definice funkce $u(T_i)$ jak je zaps�na vztahem (\ref{eq:uti}) nen� �pln�. Je�t� je nutn� doplnit omezen�
\begin{equation}
  	\left( \forall i \in \left\{ 1, \dotsc ,  k \right\} \right) \left( T_i \text{ je interval typu 3} \right) : \quad
  	 -u(T_i) < Q_{V}^{(i-1)} 
	\label{eq:uti-omez}
\end{equation}

Tato podm�nka ��k�, �e pokud z fronty pouze odj�d�j� vozidla, nesm� se st�t, aby voln� kapacita po vypr�zdn�n� fronta byla zapo��t�na do hodnocen�. V tuto chv�li toti� nep�ij�d�j� ��dn� vozidla, kter� by k�i�ovatkou projela bez zastavov�n�.

Pokud vyjde v n�jak�m okam�iku $Q_V^{(i)}$ z�porn�, p�edstavuje (odhadovan�) po�et aut, kter� mohou  v tomto intervalu k�i�ovatkou projet bez zastaven� a~tato hodnota se tedy ode�te od hodnocen� dan� k�i�ovatky (a~t�m se hodnocen� zv���). 

Vyvst�v� ot�zka jak zjistit aktu�ln� d�lky front na jednotliv�ch j�zdn�ch pruz�ch jen pomoc� �daj� z~detektor�, kter� jsou k~dispozici. Ukazuje se, �e toto nen� trivi�ln� probl�m a~jeho �e�en� p�esahuje r�mec t�to pr�ce. Z~toho d�vodu nejsou v~programu d�lky front odhadov�ny tak, jak by to bylo nutn� v~re�ln� situaci, ale pou��vaj� se hodnoty, kter� lze z�skat ze simul�toru Aimsun pomoc� VGS API. Podrobn�j�� informace o~modelov�n� d�lky fronty p�edstavuje nap��klad \cite{pecherkova}. VGS API fronty po��t� t�m zp�sobem, �e projde cel� p��slu�n� j�zdn� pruh a v n�m do fronty zapo��t� ta vozidla, kter� jedou ni��� ne� stanovenou hrani�n� rychlost�. 
 
P�i samotn�m vyjedn�v�n� pak maj� agenti dv� role, jedna z~nich je zvan� \emph{pasivn�}, druh� je pak tedy \emph{aktivn�}. Pasivn� agent m� pevn� nastaven� offset a~jen reaguje na pokyny aktivn�ho. Pokyny tvo�� bu� ��dost o~o�ek�van� �asy p��jezd� nebo n�vrh na zm�nu offsetu. Na prvn� z~nich agent v�dy odpov�d� zasl�n�m po�adovan�ch �daj�, u~druh�ho pak zva�uje, jestli by zm�na v~celkov�m sou�tu p�inesla zlep�en� \texttt{ratingu}. Z~tohoto popisu u� pak vypl�v� role aktivn�ho agenta. Ten stejn� pracuje se ��dostmi o~�asy p��jezd�, nav�c ale aktivn� m�n� sv�j offset a~pokou�� se vyjednat zm�nu u~soused�.

Vyjedn�vac� cyklus pak prob�h� v~n�kolika kroc�ch. Nejprve si v�ichni agenti vy��daj� o�ek�van� p��jezdy vozidel na z�klad� offset� nastaven�ch v~minul�m cyklu. S~p�ihl�dnut�m k~t�mto o�ek�v�n�m pak aktivn� agenti spo��taj� \texttt{rating} sv�ho nastaven� offsetu a~pokus� se zjistit, jestli by n�jak� zm�na vlastn�ho offsetu nevedla ke zlep�en� hodnocen�. 

Hled�n� nejlep��ho vlastn�ho offsetu prob�h� ve t�ech kroc�ch. Nejprve se porovn� aktu�ln� offset, offset zv��en� o~8 sekund a~offset sn�en� o~8 sekund. Vybere se nejl�pe hodnocen� z t�chto mo�nost� a~pokra�uje se s~n�m stejn�m zp�sobem, jen dal�� uva�ovan� zm�na je $\pm4$ sekundy. V~posledn�m kroku je pak otestov�n posun o~$\pm2$ sekundy.

Kdy� aktivn� agenti naleznou sv� nejlep�� offsety, roze�le se v�em ��astn�k�m zpr�va o~nalezen� stabiln�ho stavu, kter� obsahuje nov� hodnoty o�ek�van�ch p��jezd� vozidel. Nyn� aktivn� agenti vyzkou��, jestli by k~dal��mu zlep�en� nevedla zm�na offsetu u~n�kter�ho z~jejich soused�. Podobn�m zp�sobem jako p�i hled�n� vlastn�ho nejlep��ho offsetu zkus� odhadnout zm�nu \texttt{ratingu} p�i posunu sousedova offsetu o~$\pm4$ a nejlep�� ze t�� mo�nost� se za�le jako ��dost o posun offsetu sousedovi spolu se zm�nou \texttt{ratingu}, kterou by p�inesla.

Ka�d� pasivn� agent pot� sesb�r� v�echny n�vrhy a~otestuje, kter� z~nich m� nejv�t�� sou�et zm�ny ratingu u~n�j samotn�ho a~zm�ny u~navrhovatele a~ten potom p�ijme za vlastn�. Pokud by v�echny n�vrhy p�inesly z�pornou zm�nu, jsou zam�tnuty a~��dn� zm�na nenast�v�. V~ka�d�m p��pad� jsou pak rozesl�ny informace o~nov�m stabiln�m stavu a~s~nimi op�t o�ek�van� p��jezdy. 

Pot� se je�t� zas�l�n� ��dost� opakuje, jen s posunem o $\pm2$ a $\pm1$ sekundu. 

T�mto ka�d� k�i�ovatka nalezne sv�j kone�n� offset. Probl�m nast�v� p�i zasl�n� tohoto offsetu do �adi�e k�i�ovatky. Od toho nen� garantov�na okam�it� akce, zp�sob jak�m ��dan�ho offsetu dos�hne je jen v~jeho re�ii a~ne� se tak stane m��e trvat i~n�kolik cykl�. Z~tohoto d�vodu se vypo�ten� offset nepos�l� hned po nalezen�, ale agent v�dy v~p�ti cyklech napo��t� optim�ln� offset, z~t�chto p�ti hodnot spo��t� pr�m�r a~a� ten se n�sledn� p�ed� �adi�i pro zpracov�n�. T�m je tak� sn�ena reaktivnost agenta a~zamez� se p��padn�m p�ehnan�m reakc�m na chvilkov� zm�ny popt�vky, kter�m stejn� nen� mo�n� se p�izp�sobit.

\section{Pou�it� knihovny}
Pro usnadn�n� pr�ce a~tak� z~d�vodu lep��ho za�len�n� do sou�asn�ho �e�en� se v~programu pou��vaj� t�i voln� dostupn� knihovny: \texttt{IT++}, zjednodu�uj�c� pr�ci s~vektory, maticemi a~poli, \texttt{BDM} (Bayesian Decision Making), kter� obsahuje u�ite�n� n�stroje pro pr�ci s~popisy k~vektor�m a~obsahuje tak� n�stroj pro ukl�d�n� pr�b�n�ch hodnoot z~experimentu a~\texttt{libconfig}, slou��c� p�edev��m pro pr�ci s~konfigura�n�mi soubory. Prvn� dv� knihovny jsou distribuov�ny pod GPL licenc�, t�et� pak pod licenc� LGPL.

\subsection{IT++}
\texttt{IT++} je knihovna pro C++, kter� obsahuje t��dy a~funkce pro prov�d�n� n�kter�ch matematick�ch operac�, zpracov�n� sign�l� a~dal��. Pro ��ely t�to pr�ce jsou zaj�mav� pr�v� funkce matematick�. 

Pro zach�zen� s~vektory jsou v~knihovn� mimo jin� zavedeny typy \texttt{vec} a~\texttt{ivec}. Prvn� jmenovan� je vektor obsahuj�c� prvky typu \texttt{double}, tedy ��sla s~desetinou ��rkou, druh� je pak slo�en z~prvk� \texttt{int}, �ili ��sel cel�ch. Pr�ce s~vektory je velmi intuitivn�, nav�c lze �asto pou��vat syntaxi podobnou jako v~programu MATLAB.

Vektor m��eme nadefinovat jedn�m z~t�chto zp�sob�
\lstset{language=C++, showstringspaces=false}
\begin{lstlisting}
vec my_vector;
vec my_vector(10);
\end{lstlisting}
p�i�em� prvn� z~nich pro vektor nealokuje pam�. To je pak nutn� ud�lat funkc� \lstinline{setsize()}. N�sledn� je pak mo�n� ulo�it do vektoru jednotliv� prvky a~to nap��klad jedn�m z~n�sleduj�c�ch p��kaz�.
\begin{lstlisting}
vec  a = "0 0.7 5 9.3";        // tedy a = [0 0.7 5 9.3]
ivec b = "0:5";                // tedy b = [0 1 2 3 4 5]
vec  c = "3:2.5:13";           // tedy c = [3 5.5 8 10.5 13]
ivec d = "1:3:5,0:2:4";        // tedy d = [1 3 5 0 2 4]
vec e("1.2,3.4,5.6");          // tedy e = [1.2 3.4 5.6]
\end{lstlisting}
Nav�c lze i-t�mu prvku vektoru \texttt{a} p�istupovat pomoc� \lstinline!a(i)! nebo \lstinline[]!a[i]!. 

D�ky p�et�en� oper�tor� lze s~vektory p��mo prov�d�t b�n� matematick� operace, jako jsou:
\begin{lstlisting}
a+b	// sou�et vektor�
a+5	// p�i�ten� ��sla 5 ke v�em prvk�m vektoru
a*b	// skal�rn� sou�in vektor�
a*9	// vyn�soben� v�ech prvk� vektoru ��slem 9
\end{lstlisting}
a~tak podobn�.

Pr�ce s~maticemi pak funguje podle obdobn�ch pravidel.

D�le se v~knihovn� nach�z� t��da \texttt{Array}. D�ky n� je mo�n� vytv��et pole prvk� libovoln�ho typu (v�etn� v��e popsan�ch vektor�) a~prov�d�t s~nimi mnoh� operace. P��kladem u�it� pr�v� pro pole vektor� je nap��klad n�sleduj�c� k�d:
\begin{lstlisting}
Array<vec> pole_vektoru(2);
my_vec_array(0) = "2 4 5 0 3";;
my_vec_array(1) = "0.1 0.2 0.3 0.4 0.3 0.2 0.1";
\end{lstlisting}
U~takto definovan�ho pole pak lze pak intuitivn� p�istupovat k~jeho prvk�m pomoc� \lstinline!pole_vektoru(i)! a~nav�c prov�d�t operace jako jsou posuny prvk�, v�b�r podmno�iny prvk� nebo t�eba prost�edn�ho prvku a~mnoh� dal��.

\subsection{BDM}
Knihovna \texttt{BDM} (Bayesian Decision Making) se zab�v�, jak n�zev napov�d�, bayesovsk�m rozhodov�n�m. Ov�em v~t�to pr�ci jsou z~n� p��mo pou�ity jen n�kter� t��dy, jmenovit� \texttt{UI}, \texttt{RV}, \texttt{datalink} a~\texttt{logger}. BDM nav�c definujeme t��du \texttt{Participant}, kter� je z�kladem rozhodovac�ch proces� a od kter� se pak odvozuje agent pro ��zen� dopravy.

T��da \texttt{UI} (User Info) slou�� pro ukl�d�n� a~�ten� libovoln�ch u�ivatelsk�ch dat. Zde se pou��v� pro na�ten� konfigurace pro simul�tor a~pro jednotliv� agenty a~d�le jako form�t pro ukl�d�n� a~pos�l�n� zpr�v mezi agenty.

��elem t��dy \texttt{RV} je poskytovat popisn� informace k~datov�mu vektoru. Prom�nn� typu \texttt{RV} se skl�d� z~jedn� nebo n�kolika polo�ek. Ka�d� takov� polo�ka m� svoje jm�no (\texttt{name}) a~d�lku -- po�et prvk�, kter� tomuto jm�nu odpov�daj�. Sou�et d�lek v�ech takov�chto polo�ek se potom mus� rovnat d�lce vektoru, kter� je danou prom�nnou typu \texttt{RV} popisov�n. Fungov�n� je ilustrov�no na obr�zku \ref{fig:rv}.

\begin{figure}%
	\centering
	\includegraphics[width=7cm]{rv}%
	\caption{Vektor typu \texttt{RV} (vlevo) funguj�c� jako popis k~vektoru typu \texttt{vec}~(vpravo). Ka�d� polo�ka z~\texttt{rv\_vector} m� v~lev�m sloupci sv� jm�no (\texttt{name}) a~v~prav�m velikost (\texttt{size}). V~tomto p��pad� se tedy podvektor \texttt{c} rovn� vektoru [5~4]}%
	\label{fig:rv}%
\end{figure}

Pro kop�rov�n� dat mezi vektory existuje t��da \texttt{datalink}. Vytv��� spojen� mezi dv�ma datov�mi vektory na z�kladn� shodn� pojmenovan�ch prvk� v~k~nim p��slu�n�ch popisn�ch vektorech. Po propojen� vektoru s~podvektorem pak funkce data\-linku umo��uj� snadn� kop�rov�n� dat ob�ma sm�ry.

Na z�v�r \texttt{Logger} je t��da ur�en� pro ukl�d�n� dat z~programu. Tvo�� abstraktn� vrstvu mezi programem a~samotn�m z�pisem dat. P�i pou�it� se jen na za��tku nastav� v~jak� form� chceme z�skat v�sledn� �daje (nap�. ulo�it do pam�ti, do souboru, do datab�ze, atd.) a~d�le t��du pou��v�me bez ohledu na tuto volbu. Je t�m zaji�t�na flexibilita pro p��pad, �e se zm�n� po�adavky na v�stupy z~programu.

\subsection{Libconfig}
Konfigura�n� parametry pro simulaci se ukl�daj� do souboru ve form�tu, kter� zav�d� knihovna \texttt{libconfig}. Jde o~textov� form�t, kter� je stru�n�j�� a~pro �lov�ka l�pe �iteln�, ne� XML. 

Podporovan� form�t soubor� p�edstavuje hierarchickou strukturu. \emph{Konfigurace} se skl�d� ze skupiny \emph{nastaven�}, kter� p�i�azuje \emph{jm�n�m} \emph{hodnoty}. Hodnotou m��e b�t \emph{skal�r}, \emph{pole}, \emph{skupina} nebo \emph{seznam}. Skupiny nastaven� je mo�n� do sebe d�le vno�ovat, ��m� knihovna nab�z� velmi flexibiln� a p�itom st�le p�ehledn� zp�sob pro ukl�d�n� konfigura�n�ch soubor�.

\section{VGS API}
Velmi d�le�it�m �kolem p�i simulaci re�ln� oblasti v~mikrosimul�toru Aimsun je vlo�en� re�ln�ch vstupn�ch intenzit dopravy do zkouman�ho modelu. B�n�m postupem je ru�n� s��t�n� vozidel v~dan� oblasti, zpravidla v~hodinov�m rastru. Takto z�skan� data je mo�n� vlo�it do simul�toru Aimsun jako hodinov� z�t�e, ov�em toto je t�eba prov�st tak� ru�n�.

%Jedn�m z nejd�le�it�j��ch �kol� p�i simulaci re�ln�ho zat�en� dopravn�� s�t� v mikrosimul�toru Aimsun je zat�en� cel� simulovan� dopravn� s�t� re�ln�mi vstupn�mi intenzitami dopravy, odpov�daj�c�mi m��en�m v simulovan� s�ti. P�i b�n�ch postupech se intenzity dopravy ur�uj� pomoc� ru�n�ho s��t�n� dopravy, zpravidla v hodinov�m rastru. Data, z�skan� t�mto postupem, je mo�no potom p��mo vlo�it op�t ru�n� do Aimsunu jako hodinov� dopravn� z�t�e.

P�esn�j�� mo�nost� je z�skat intenzity provozu z~dat z�skan�ch p��mo z~dopravn�ch detektor� instalovan�ch v~p�edm�tn� oblasti. To v�ak znamen� ru�n� zad�n� stovek �daj� do simul�toru. Pr�v� z~tohoto d�vodu vzniklo VGS API. To se star� o~nastartov�n� Aimsunu a~vpou�t�n� vozidel do oblasti. Vjezdy vozidel se p�i tom ��d� �daji v~extern�m souboru, obsahuj�c�m intenzity na jednotliv�ch ramenech. U�ivatel pak jen zad� jm�no a~um�st�n� tohoto souboru a~v�e ostatn� se d�je automaticky. Nav�c lze volit mezi r�zn�mi rozd�len� pravd�podobnosti vjezd�, p�i�em� nej�ast�ji pou��van� je rovnom�rn� �i Poissonovo rozd�len�.

%Pokud se sna��me o p�esn�j�� simulaci, m��eme pro zati�en� dopravn� s�t� pou��t data z�skan� p��mo z dopravn�ch detektor� instalovan�ch v simulovan� oblasti. V takov�m p��pad� by bylo pot�eba ru�n� vkl�dat n�kolik set hodnot vstupn�ch intenzit pro ka�d� simulovan� den. VGS API vzniklo ve snaze tento handicap odstranit -- na za��tku simulace rozhran� pouze u�ivatewl p�ed� informace o tom, kde je um�st�n soubor s intenzitami vjezd� do jednotliv�ch ramen a o jak� vjezdov� ramena jde, VGS API se automaticky postar� o nastartov�n� Aimsunu a automaticky vpou�t� vozidla do syst�mu podle �daj�, obsa�en�ch v souboru s intenzitami vjezd�. U�ivatel m��e volit r�zn� druhy rozd�len� pravd�podobnosti vjezd�, nej�ast�ji se pou��v� rovnom�rn� nebo Poissonovo rozd�len�.

Vedle pr�ci se vstupn� daty pro simulaci se VGS API star� i~o~zpracov�n� dat v�stupn�ch. Aimsun sice zvl�d� export v�sledk� simulac� do textov�ch soubor� a~obsahuje i~n�stroje pro jejich vizualizaci, neumo��uje p��mo ale n�kter� d�le�it� v�ci jako je nap��klad porovn�n� v�sledk� ze dvou r�zn�ch sc�n���. VGS proto v~pr�b�hu cel�ho experimentu ukl�d� �daje o~sledovan� oblasti a~to jak pro jednotliv� sekce, tak pro cel� syst�m. Ve v�sledku u�ivatel z�sk�v� informace o~po�tu zastaven� vozidel, o~jeho zpo�d�n�, pr�m�rn� rychlosti, dob� j�zdy a~dob� st�n�, o~doprav�m toku a~hustot� dopravy na jednotliv�ch segmentech �i o~d�lk�ch front vozidel. �daje o~d�lk�ch front jsou specialitou VGS, Aimsun tento �daj pro jednotliv� j�zdn� pruhy p��mo neposkytuje a~VGS m� proto implementov�n vlastn� algoritmus pro jejich s��t�n�.

%Druh�m d�le�it�m �kolem VGS API je zhroma��ovat data pot�ebn� pro vyhodnocen� experimentu. Aimsun sice disponuje jednoduch�m rozhran�m pro vizualizaci dat a jejich export do textov�ch soubor�, nen� ale mo�n� nap��klad porovn�vat jednotliv� sc�n��e simulac�. VGS API proto periodicky ukl�d� v�echny kl��ov� ukazatele jak pro jednotliv� segmenty dopravn� s�t�, tak i pro cel� simulovan� syst�m. U�ivatel m� po ukon�en� simulace k dispozici �daje o po�tu zastaven� vozidla, o jeho zpo�d�n�, pr�m�rn� rychlosti, dob� j�zdy a dob� st�n�, o doprav�m toku a hustot� dopravy na jednotliv�ch segmentech �i o d�lk�ch front vozidel. Vzhledem k tomu, �e Aimsun neposkytuje informace o d�lce fronty vozidel pro ka�d� na j�zdn� pruh zvl᚝ (k dispozici jsou pouze �daje o akumulovan� d�lce fronty vyj�d�en� po�etm vozuidel, kter� na segmentu dopravn� s�t� v dan� okam�ik stoj�), m� VGS API implementovan� vlastn� algoritmus v�po�tu d�lky fronty vozidel na ka�d�m j�zdn�m pruhu a poskytuje u�ivateli i takto z�skan� informace o d�lce fronty.

Implementac� VGS API je DLL knihovna napsan� v~jazyce C pro 32 a~64 bitov� syst�my Windows XP a~v��e. Nav�c je sou��st� VGStoolbox, sada skript� pro zpracov�n� v�stupn�ch dat v~programu Matlab.

%Vlastn� VGS API je implementov�no v jazyce C jako DLL pro 32- a 64-bitov� syst�my po��naje Windows XP, rozhran� je dopln�no funkcemi pro obsluhu API a vyhodnocov�n� statistick�ch informac� v prost�ed� n�stroje Matlab 

\section{Struktura programu}

Fungov�n� simula�n�ho prost�ed� tak jak bylo navr�eno v~�TIA je na obr�zku (\ref{fig:struktura}). Skl�d� se ze t�� hlavn�ch blok�, mikrosimul�toru Aimsun, emul�tor� �adi�� ELS3 a~z~tzv. Aimsun agenta.

Aimsun agent p�edstavuje ��d�c� prvek cel�ho syst�mu. P�es \texttt{vgs\_api} spou�t� Aimsun a~stejn�m zp�sobem od n�j pr�b�n� p�ij�m� hodnoty sledovan�ch dopravn�ch veli�in. D�le prost�ednictv�m \texttt{eh\_api} z�sk�v� �daje z~�adi�� k�i�ovatek. Na z�klad� v�ech sesb�ran�ch �daj� pak sestavuje pokyny pro zm�ny v~sign�ln�ch pl�nech a~op�t pomoc� \texttt{e\_api} tyto pokyny zas�l� �adi��m. 

Na z�v�r komunikace mezi mikrosimul�torem a~emul�tory �adi��, kter� obsahuje �daje z~detektor� v~jednom sm�ru a~ze stav� sign�ln�ch skupin ve druh�m, prob�h� p�es \texttt{ea_api}.

\begin{figure}%
\centering
\includegraphics[width=\columnwidth]{aimsun-agents}%
\caption{Komunikace jednotliv�ch komponent simula�n�ho prost�ed�}%
\label{fig:struktura}%
\end{figure}

\section{Program main_loop.exe}
\label{sec:main_loop}

Simulace je obsluhov�na z~programu \emph{main\_loop.exe}. Ten se star� o~na�ten� konfigurace, spu�t�n� simul�toru Aimsun a~zaji��uje komunika�n�ho prost�edn�ka mezi jednotliv�mi agenty. 

Konfigura�n� soubor obsahuje n�kolik prvk�. Seznam \texttt{list}) \texttt{agents} se skl�d� z~popisu jednotliv�ch agent�. P�edev��m je definov�na t��da, jej� instance agenta p�edstavuje a~unik�tn� jm�no agenta (\texttt{name}). Dal�� prom�nn� jsou pak z�le�� na pou�it� t��d� pro konstrukci agenta, ka�d� m��e m�t sv� specifick� po�adavky. Skupina (\texttt{group}) \texttt{logger} ur�uje, jak n�zev napov�d�, t��du pou�itou pro logov�n� �daj� b�hem simulace. Skupina \texttt{system} obsahuje parametry pro simul�tor a~konfigura�n� soubor uzav�raj� ostatn� u�ite�n� prom�nn� nespadaj�c� do v��e uveden�ch kategori�.

Komunikaci program zaji��uje obsluhou fronty zpr�v a~ta vlastn� definuje z�klad pou�it�ho komunika�n�ho protokolu. Zpr�vy jsou ve form�tu knihovny \texttt{libconfig} a~obsahuj� n�kolik povinn�ch a~libovoln� po�et voliteln�ch slo�ek. Nezbytn�mi �daji jsou �et�zec \texttt{to}, obsahuj�c� p��jemce zpr�vy a~�et�zec \texttt{what}, kter� zna�� p�edm�t zpr�va. Dal�� roz���en� zpr�v je pak na pot�eb�ch pou�it�ch agent�.

Program se d� rozd�lit na samostatn� bloky tak, jak je zobrazeno na obr�zku \ref{fig:mainloop}. Z~tohoto n�kresu bude vych�zet n�sleduj�c� popis.

\begin{figure}[t]%
\centering
\includegraphics[width=8.5cm]{mainloop3}%
\caption{Strukuta fungov�n� programu \texttt{main_loop.exe}, podrobn�ji popsan� v~podkapitole \ref{sec:main_loop}}%
\label{fig:mainloop}%
\end{figure}

B�hem \emph{inicializace} je na�ten konfigura�n� soubor, jeho� jm�no se p�ed�v� jako jedin� parametru p�i spou�t�n� \texttt{main_loop.exe}. Po na�ten� jsou parametry ze skupiny \texttt{system} p�ed�ny VGS API, kter� se postar� o~spu�t�n� Aimsunu s~t�mito parametry. Jde p�edev��m o~intenzitu provozu na vstupech do dopravn� s�t� a~d�lku simulace.

N�sledn� je dle konfigurace vytvo�eno pole ukazatel� na agenty \texttt{Ags}. P�i konstrukci jednotliv�ch agent� je vol�na jejich funkce \texttt{from_setting()} na��taj�c� konkr�tn� parametry ka�d�ho agenta.  

Pot� se vytv��� instance t��dy \texttt{logger} a~jej� prov�z�n� s~agenty. V~tu chv�li se pou�t� i~funkce \texttt{ds_register()} umo��uj�c� aktualizaci datalink� pro spojen� mezi agenty a~simul�torem. Na z�v�r tohoto bloku programu je provedena inicializace fronty zpr�v a~zaregistrov�n� vektor� kter� se budou v~pr�b�hu simulace logovat.

D�le se pokra�uje �st�edn�m for cyklem. ��st \texttt{z�sk�n� dat} v~sob� zahrnuje ulo�en� logovan�ch hodnot ze simul�toru a~pak p�edev��m ulo�en� vektor $d_t$ do prom�nn� \texttt{glob_dt} a~jeho odesl�n� agent�m ke zpracov�n� funkc� \texttt{adapt()}. Pot� p�ich�z� na �adu vyjedn�vac� cyklus.

Vyjedn�vac� cyklus se zab�v� obsluhou fronty zpr�v. Nejprve prob�hne \emph{doru�en� zpr�v}, kter� jsou aktu�ln� ve front�. V~prvn�m kroku vyjedn�vac�ho cyklu je fronta zpr�v samoz�ejm� pr�zdn�, v~n�sleduj�c�m se od konce proch�z� a~adresovan�m agent�m jsou p�ed�ny p��slu�n� zpr�vy. To se d�je zavol�n�m funkce \texttt{recieve()} se zpr�vou jako parametrem. V~p��pad�, �e adres�t nen� nalezen a~zpr�vu tedy nelze doru�it je ozn�meno varov�n�, ale pokra�uje se d�l v~�innosti. 
	
Po vypr�zdn�n� fronty nast�v� �as pro \emph{vys�l�n� zpr�v}. To spo��v� ve spu�t�n� funkce \texttt{broadcast()} u~v�ech agent�. V~n� maj� p��le�itost vlo�it do fronty zpr�v libovoln� po�et sd�len� pro ostatn� agenty, nemus� ov�em vys�lat ��dn�.

Dal�� postup z�vis� na stavu fronty zpr�v. Pokud je pr�zdn�, tedy ��dn� agent nevyslal ��dnou zpr�vu, kon�� vyjedn�vac� cyklus a~pokra�uje se v~b�hu programu. V~p��pad�, �e fronta pr�zdn� nen�, cyklus se opakuje a~prob�hne dal�� doru�ov�n� zpr�v z~fronty. Vyjedn�v�n� m��e b�t ukon�eno je�t� v~p��pad�, kdy prob�hne stanoven� maxim�ln� po�et vyjedn�vac�ch cykl�, nastaven� v~prom�nn� \texttt{max_cycles}. Limit by v�ak m�l b�t nastaven tak, aby k~jeho dosa�en� nedoch�zelo, pokud se tak stane, m�lo by to b�t sign�lem probl�mu v~programu.

Posledn� ��st hlavn�ho cyklu je nazvan� \emph{krok simulace}. Spo��v� nejprve v~zavol�n� funkce \texttt{act()} u~ka�d�ho agenta. To je okam�ik, kdy mohou agenti ovlivnit ��zen� signalizace. Pr�v� zde prob�h� zkop�rov�n� vypo��tan�ch hodnot do vektoru \mbox{\texttt{glob_ut}}, tedy do prom�nn� p�edstavuj�c� vektor vstupn�ch hodnot $u_t$. Na z�v�r hlavn�ho cyklu je cel� simulace posunuta o~jeden krok d�le vol�n�m funkc� \texttt{step()} u~loggeru \texttt{L}, \texttt{Ds} a~u~v�ech agent�. D�lka kroku je pevn� nastavena na 90~s, je to z~d�vodu, �e v~Praze jsou �daje z~detektor� sb�r�ny pr�v� v~tomto intervalu.

Tato smy�ka se opakuje dokud nen� dosa�en v~konfigura�n�m souboru nastaven� �as simulace. \emph{Zakon�en�} spo��v� ji� jen v~zaps�n� log souboru.

\section{Implementace navr�en�ho algoritmu}

Algoritmus popsan� v~kapitole \ref{sec:navrh} je implementov�n pomoc� agent�, kte�� jsou instancemi t��dy \texttt{GreenWaveTrafficAgent}.

T��da je odvozena od p�edka jm�nem \texttt{BaseTrafficAgent}. Ten slou�� jen jako prakticky pr�zdn� agent, po p�i�azen� k~n�jak� k�i�ovatce nekon� ��dnou akci a~umo��uje tak simulovat syst�m bez decentralizovan�ho ��zen�. P�edkem t�to t��dy je t��da \texttt{Participant} z~knihovny BDM. \texttt{Participant}, tedy ��astn�k, p�edstavuje z�kladn� jednotku v~rozhodovac�m procesu. Ka�d� ��astn�k m� sv� jm�no (\texttt{name}) a~je schopen ukl�dat v�sledky. U� pr�v� t��da \texttt{Participant} deklaruje existenci funkc� \texttt{adapt()}, \texttt{broadcast()}, \texttt{recieve()}, \texttt{act()} a~\texttt{step()}. Tyto jsou v~n�m definov�ny jako virtu�ln� (\texttt{virtual}), tedy pokud je v~potomkovi redefinujeme, je zaru�eno vol�n� t�chto nov�ch funkc�.

\subsection{Ve�ejn� funkce}

Ve�ejn� (\texttt{public}) funkce ve t��d� \texttt{GreenWaveTrafficAgent} p�episuj� funkce definovan� v~p�edc�ch a~p�edstavuj� rozhran� pro komunikaci s~hlavn�m programem a~t�m i~ostatn�mi agenty.

Prvn� po vytvo�en� instance agenta prob�hne zavol�n� funkce \texttt{from_setting()}. V~t� se nejprve vol� stejnojmenn� funkce p�edka, kter� na��t� z~konfigurace z�kladn� parametry, jmenovit�:
\begin{description}
	\item[lanes] Informace o~j�zdn�ch pruz�ch,
	\item[neighbours] Jm�na agent� u~sousedn�ch k�i�ovatek,
	\item[green_names] Jm�na jednotliv�ch sign�ln�ch skupin,
	\item[green_starts] �as, ve kter� p��slu�n� sign�ln� skupiny rozsv�c� zelenou,
	\item[green_times] D�lka trv�n� sv�cen� zelen� dan� sign�ln� skupiny, uv�d�na jako pom�r $\text{doba sv�cen�}/\text{d�lka cyklu}$, 
\end{description}
a~n�kter� dal��, kter� pro tuto pr�ci nejsou d�le�it�.

Popis jednotliv�ch j�zdn�ch pruh� si zaslou�� podrobn�j�� rozebr�n�. Ten toti� pro agenta p�edstavuje st�ejn� ��st informac� a~topologii j�m ��zen� k�i�ovatky. Do konfigura�n�ho souboru se uv�d�j� v�echny takov� j�zdn� pruhy, kter� kon�� n�jakou stop ��rou dan� k�i�ovatky. Ka�d� j�zdn� pruh pak m� n�sleduj�c� parametry:  \texttt{sg}, co� je sign�ln� skupina do kter� pat��, \texttt{inputs} je seznam detektor� na vjezdu do tohoto pruhu, \texttt{outputs} je seznam detektor� na sousedn�ch k�i�ovatk�ch, ke kter�m m��e vozidlo z~tohoto pruhu dojet. Pokud se vozidla mohou dostat do m�st, kde ��dn� detektor nen�, je zde za ka�d� takov�to sm�r uveden �fale�n�� detektor \texttt{DUMMY_DET}. D�le konfigurace obsahuje \texttt{input_distances}, pole vzd�lenost� vstupn�ch detektor� od stop ��ry, podobn� \texttt{output_distances} je pole vzd�lenost� v�stupn�ch detektor� (u~�fale�n�ch� nehraje roli), \texttt{alpha} je pole pom�r� odbo�en� k~jednotliv�m v�stupn�m detektor�m, \texttt{queue} jm�no fronty, kter� se na dan�m pruhu tvo�� a~kone�n� \texttt{beta} je koeficient, kter�m se n�sob� d�lka fronty b�hem v�po�t�, kter� agent prov�d�.

Agent po z�sk�n� informac� o~j�zdn�ch pruz�ch pro ka�d� vytvo�� instance t��d \texttt{Lane} a~\texttt{LaneHandler}. ty p�edstavuj� mezivrstvu mezi agentem a~fyzick�m j�zdn�m pruhem se skute�n�mi detektory.

D�le se ve funkci \texttt{from_setting()} nastavuj� hodnoty konstant a~v�choz� hodnoty n�kter�ch prom�nn�ch. Konkr�tn� jde
o~\begin{description}
	\item[car_leaving_time] �as v~sekund�ch, ze kter� jedno auto opust� frontu ($c_0$)
	\item[VP] Pr�mern� rychlost j�zdy automobilu mezi k�i�ovatkami na voln� silnici ($v_P$)
	\item[actual_time] Uchov�v� aktu�ln� �as simulace (v~sekund�ch)
	\item[negot_cycle] Po�et ji� prob�hl�ch vyjedn�vac�ch cykl� od posledn�ho pr�m�rov�n�
	\item[cycle_count] Hranice po�tu cykl�, po jej�m� dosa�en� nast�v� pr�m�rov�n� z�skan�ch offset�
	\item[total_offset] Hodnota sou�tu dosud vyjednan�ch offset� od posledn�ho pr�m�rov�n�
	\item[negot_start] Krok, kter�m se za��n� p�i hled�n� ide�ln�ho offsetu u~souseda
	\item[negot_limit] Krok, kter�m se kon�� p�i hled�n� ide�ln�ho offsetu u~souseda
	\item[find_best_start] Krok, kter�m za��n� hled�n� nejlep��ho vlastn�ho offsetu
	\item[find_best_limit] Krok, kter�m kon�� hled�n� nejlep��ho vlastn�ho offsetu
	\item[passive] Indikuje zda agent zast�v� pasivn� nebo aktivn� roli
\end{description}

Hodnoty konstant lze z v�choz�ch hodnot p�epsat uveden�m prom�nn� v konfigura�n�m souboru.

V~z�v�ru jsou je pak z~konfigurace na�ten v�choz� offset, role agenta a~p�ipraven vektor v�stupn�ch hodnost \texttt{outputs} spolu s~jeho popisem \texttt{rv_outputs}. Na �pln�m konci je je�t� zapnuto logov�n� hodnot offset� pro pozd�j�� vyhodnocen�.

\lstset{language=[Visual]C++,showstringspaces=false,numbers=left, numberstyle=\tiny, numbersep=0pt, tabsize=2, breaklines, breakautoindent=false, captionpos=b}
%\begin{lstlisting}[caption=Funkce from_setting(), label=lst:from, firstnumber=587]
%	void from_setting(const Setting &set) {
%		BaseTrafficAgent::from_setting(set);
%
%		RV rv_exp;
%
%		car_leaving=2;
%		VP=45;
%		actual_time=0;
%		
%		negoT_{\mathrm{c}}ycle=1;
%		cycle_count=5;
%		total_offset=0;
%
%		negot_offset=4;
%		negot_limit=1;
%
%		passive=0;
%		
%		UI::get(last_offset, set, "offset", UI::compulsory);
%		UI::get(passive, set, "passive", UI::optional);
%
%		for (int i=0;i<lanes.length();i++) {
%			for (int j=0;j<lanes(i).outputs.length();j++) {
%				if (lanes(i).outputs(j)!="DUMMY_DET") {
%					rv_exp=RV(lanes(i).outputs(j)+"-"+name+"_"+to_string(i),3);
%					rv_outputs.add(rv_exp);
%				}
%			}
%		}
%		outputs.set_size(rv_outputs._dsize());	
%
%		log_level[logoffset]=true;
%	}
%\end{lstlisting}

Dal�� volanou funkc� v~agentech je \texttt{adapt()}. Podobn� jako \texttt{from_setting()} nejprve spou�t� stejnomenou funkci u~sv�ho p�edka. V~t� prob�h� vypln�n� vektor� \texttt{inputs} a~\texttt{queues} daty z~Aimsunu, ulo�en�mi ve vektoru \texttt{glob_dt}. �daje z~\texttt{queues} se p�edaj� p��slu�n�m \texttt{LaneHandler}�m. D�le je nastaven \texttt{planned_offset} na hodnotu z�skanou v~minul�m cyklu a hodnoty stavov�ch prom�nn�ch jsou vr�ceny do sv�ch v�choz�ch hodnot.

%\begin{lstlisting}[caption=Funkce adapt(), label=lst:adapt, firstnumber=415]
%	void adapt(const vec &glob_dt) {
%		BaseTrafficAgent::adapt(glob_dt);
%			
%		for (int i=0;i<lanehs.length();i++) {
%			lanehs(i)->queue=queues(lanehs(i)->queue_index);		
%		}
%
%		planned_offset=last_offset;
%		
%		//set state variables to default values
%		final_state=false;
%		new_stable_state=false;
%		send_requests=false;
%		need_exps=true;
%		negot_offset=4;
%	}
%\end{lstlisting}

Funkce \texttt{recieve()} zpracov�v� p�ijat� zpr�vy od ostatn�ch agent�. Na za��tku je p�ijat� zpr�va rozd�lena do jednotliv�ch prom�nn�ch.

%\begin{lstlisting}[caption={Fragment funkce \texttt{recieve()}, inicializace}, label=lst:recieveInit, firstnumber=491]
%	void receive(const Setting &msg){
%		string what;
%		string to;
%		string from;
%		vec value;
%		RV *rv;
%		
%		UI::get(what, msg, "what", UI::compulsory);
%		UI::get(to, msg, "to", UI::compulsory);
%		UI::get(from, msg, "from");
%		UI::get(rv, msg, "rv");
%		UI::get(value, msg, "value");
%\end{lstlisting}

D�le se �innost li�� podle �p�edm�tu� zpr�vy, tedy podle �et�zce ulo�en�ho v~��sti \texttt{what}. V~p��pad� p�ijet� ��dosti o~o�ek�van� �asy p��jezd� je jen ulo�eno jm�no odes�latele do seznamu �adatel� \texttt{requesters}.

%\begin{lstlisting}[caption={Fragment funkce \texttt{recieve()}}, label=lst:recieveExpReq, firstnumber=last]
%		if (what=="expected_times_request"){ 
%			requesters.push_back(from);
%		} 
%				
%\end{lstlisting}

Pokud jsou naopak obsahem p�ijat� zpr�vy o�ek�van� �asy p��jezd� automobil� od souseda, aktivn� agent najde nov� optim�ln� offset pro sv�j sign�ln� pl�n a~spo��t� \texttt{rating}, pasivn� provede jen tento v�po�et. Na konci je stavov� prom�nn� \texttt{new_stable_state} nastavena na \texttt{true}, co� ur�uje dal�� �innost agent ve f�zi vys�l�n� zpr�v.

%\begin{lstlisting}[caption={Fragment funkce \texttt{recieve()}}, label=lst:recieveNewExp, firstnumber=last]
%		else if (what=="new_expected_cars") {
%			rv_recieved_exps=*rv;
%			recieved_exps=value;
%			
%			if (!passive) {
%				planned_offset=find_best_offset(planned_offset,8);
%				planned_offset=normalize_offset(planned_offset);
%			}
%
%			planned_rating=count_rating(planned_offset, recieved_exps, rv_recieved_exps);
%			
%			// we have new stable state to broadcast
%			new_stable_state=true;
%		}
%\end{lstlisting}
Obdr�en� zpr�vy s~hlavi�kou �\texttt{stable_state}� znamen�, �e n�kter� ze soused� zm�nil sv� nastaven� offsetu a~zas�l� tedy nov� hodnoty o�ek�van�ch p��jezd�. Pokud je aktu�ln� hodnota \texttt{negot_offset} v�t�� nebo rovna \texttt{negot_limit}, zkou�� pomoc� funkce \texttt{find_best_exps()}, kter� z~hodnot $0$, $+\mathtt{negot\_offset}$ nebo $-\mathtt{negot\_offset}$ by po p�i�ten� k~sousedov� offsetu znamenala nejlep�� rating. Hodnota \texttt{negot_offset} je sn�ena na polovinu a~je p�ipraveno odesl�n� ��dosti pro souseda. Pokud byla prom�nn� \texttt{negot_offset} ji� ni��� ne� ne� \texttt{negot_limit}, p�ep�n� se agent do kone�n�ho stavu, nebo� ji� nem� dal�� prostor k~vyjedn�v�n� se sousedy. 

%\begin{lstlisting}[caption={Fragment funkce \texttt{recieve()}}, label=lst:recieveStable, firstnumber=last]
%		else if (what=="stable_state") {
%			rv_recieved_exps=*rv;
%			recieved_exps=value;
%
%			planned_rating=count_rating(planned_offset, recieved_exps, rv_recieved_exps);
%
%			if (!passive) {
%				for (int i=0;i<neighbours.length();i++) {
%					rv_change_request.add(RV(neighbours(i)+"_change",2));
%					change_request.set_size(rv_change_request._dsize()); 
%					ivec ind=RV(neighbours(i)+"_change",2).dataind(rv_change_request);
%					
%					// offset change
%					change_request(ind(0))=find_best_exps(negot_offset,neighbours(i),rating_change);
%					// rating change
%					change_request(ind(1))=rating_change;
%				}
%
%				if (negot_offset>=negot_limit) { 
%					negot_offset/=2;
%					send_requests=true;
%				}
%				else {
%					final_state=true;
%				}
%			}
%			else {
%				final_state=true;
%			}
%		}
%\end{lstlisting}
P�i p�ijet� se zpr�vy se ��dost� o~zm�nu offsetu agent zkoum�, zda je sou�et zm�ny hodnocen� po aplikaci navr�en�ho offsetu a~zlep�en� hodnocen� u~souseda, kter� od zm�ny offsetu o�ek�v�, v�t�� ne� nula. Takov�to zm�na se p�ij�m� a~podle n� se upravuje \texttt{planned_offset}. V~ka�d�m p��pad� se agent p�iprav� na zasl�n� aktu�ln�ch hodnot o�ek�van�ch p��jezd�.
%\begin{lstlisting}[caption={Fragment funkce \texttt{recieve()}}, label=lst:recieveOffChange, firstnumber=last]
%		else if (what=="offseT_{\mathrm{c}}hange_request") {
%			double final_rating_diff;
%
%			rv_recieved_changes=*rv;
%			recieved_changes=value;
%
%			for (int i=0;i<rv_recieved_changes.length();i++) {
%
%				ivec ind=RV(rv_recieved_changes.name(i),2).dataind(rv_recieved_changes);
%
%				final_rating_diff=-planned_rating+count_rating(planned_offset+(int)recieved_changes(ind(0)), recieved_exps, rv_recieved_exps)+recieved_changes(ind(1));
%				if (final_rating_diff>=0) {
%					planned_offset+=(int)recieved_changes(ind(0));
%					planned_offset=normalize_offset(planned_offset);
%					planned_rating+=final_rating_diff;
%				}
%			}
%
%			new_stable_state=true;
%		}
%\end{lstlisting}

Kdy� p�ijde zpr�va s~p�edm�tem, kter� \texttt{GreenWaveTrafficAgent} neum� zpracovat, p�ed�v� ji p�edkovi. Pokud by se stalo, �e ani ten si se zpr�vou neporad�, po�le zpr�vu sv�mu p�edkovi (tedy t��d� \texttt{bdm::Participant}), kter� v~takov�m p��pad� vyvol� varov�n� o~nezpracovateln� zpr�v�.
%\begin{lstlisting}[caption={Fragment funkce \texttt{recieve()}}, label=lst:recieveBase, firstnumber=last]
%		else {
%			BaseTrafficAgent::receive(msg);
%		}
%	}
%\end{lstlisting}

Funkce \texttt{broadcast()} vys�l� zpr�vy do fronty zpr�v a~to v~z�vislosti na hodnot�ch agentov�ch stavov�ch prom�nn�ch. Pokud nen� pr�zdn� seznam \texttt{requests}, sestav� odpov�� pro ka�d�ho z~agent� uveden�ho v~seznamu a~ten n�sledn� vypr�zdn�. D�le pak za ka�dou ze stavov�ch prom�nn�ch, kter� se rovnaj� \texttt{true} sestav� p��slu�nou zpr�vu a~hodnotu zm�n� na \texttt{false}. 

%\begin{lstlisting}[caption=Funkce broadcast(), label=lst:broadcast, firstnumber=429]
%	void broadcast(Setting& set){
%
%		//ask neighbours for exptected arrive times
%		if (need_exps) {
%			for (int i=0; i<neighbours.length(); i++){
%				Setting &msg =set.add(Setting::TypeGroup);
%				UI::save ( neighbours(i), msg, "to");
%				UI::save (name,msg,"from");
%				UI::save ( (string)"expected_times_request", msg, "what");
%			}
%			need_exps=false;
%		}
%
%		// broadcast expected cars
%		if (!requesters.empty()) {
%			double a;
%			expected_cars();
%			do {
%				Setting &msg =set.add(Setting::TypeGroup);
%				UI::save ( requesters.back(), msg, "to");
%				UI::save ( name, msg, "from");
%				UI::save ( (string)"new_expected_cars", msg, "what");
%				UI::save ( &(rv_outputs), msg, "rv");
%				UI::save ( outputs, msg, "value");
%				requesters.pop_back();
%				a=outputs (10);
%			} while (!requesters.empty());			
%		}
%
%		// broadcast new stable state (new stable expectations)
%		if (new_stable_state) {
%			expected_cars();
%			for (int i=0;i<neighbours.length();i++) {
%				Setting &msg = set.add(Setting::TypeGroup);
%				UI::save ( neighbours(i), msg, "to");
%				UI::save ( name, msg, "from");
%				UI::save ( (string)"stable_state", msg, "what");
%				UI::save ( &(rv_outputs), msg, "rv");
%				UI::save ( outputs, msg, "value");
%			}
%			new_stable_state=false;
%		}
%
%		// broadcast requests to change offset(s)
%		if (send_requests) {
%			for (int i=0;i<neighbours.length();i++) {
%				Setting &msg = set.add(Setting::TypeGroup);
%				UI::save ( neighbours(i), msg, "to");
%				UI::save ( name, msg, "from");
%				UI::save ( (string)"offseT_{\mathrm{c}}hange_request", msg, "what");
%				UI::save ( &(rv_change_request), msg, "rv");
%				UI::save ( change_request, msg, "value");
%			}
%			send_requests=false;
%		}
%	
%		// reached final offset.
%		if (final_state) {
%			final_state=false;
%		}
%	}
%
%\end{lstlisting}

Ve funkci \texttt{act()} se spo��tan� hodnota \texttt{planned_offset} p�i��t� k~hodnot� prom�nn� \texttt{total_offset} a~to a� do chv�le, ne� je v~n�m tolik hodnot, kolik stanovuje limit \texttt{cycle_count}. Kdy� se tohoto limitu dos�hne, vyd�l� se \texttt{total_offset} t�mto limitem, ��m� se z�sk� pr�m�rn� hodnotn� offsetu z~posledn�ch cykl�. Pr�m�r se pak znormalizuje, aby byl z~intervalu $\left<0;T_{\mathrm{c}}\right>$ a~ulo�� se do vektoru $u_t$, p�edstavovan�m prom�nou \texttt{global_ut}. T�m se tato hodnota dostane k~�adi�i k�i�ovatky.
%\begin{lstlisting}[caption=Funkce act(), label=lst:act, firstnumber=615]
%	void act(vec &glob_ut){
%		if (negoT_{\mathrm{c}}ycle==cycle_count) {
%			vec action;
%			action.set_size(rv_action._dsize());
%		
%			ivec index = RV(name+"_offset",1).dataind(rv_action);
%
%			action(index(0))=normalize_offset(total_offset/cycle_count, false);
%			action2ds.filldown(action,glob_ut);
%
%			total_offset=0;
%			negoT_{\mathrm{c}}ycle=1;
%		}
%		else {
%			total_offset+=planned_offset;
%			negoT_{\mathrm{c}}ycle++;
%		}
%		last_offset=planned_offset;
%	}
%\end{lstlisting}

O~z�pis aktu�ln�ch hodnot do logovac�ho souboru se star� \texttt{log_write()}. Ukl�d� se dvouslo�kov� vektor. Prvn� prvek obsahuje vypo��tan� offset \texttt{planned_offset}, druh� jeho hodnocen� \texttt{planned_rating}.

%\begin{lstlisting}[caption=Funkce log_write(), label=lst:logwrite, firstnumber=644]
%	void log_write() const {
%		if (log_level[logoffset]){
%			vec offset_vec(2);
%			offset_vec(0)=planned_offset;
%			offset_vec(1)=planned_rating;
%			log_level.store(logoffset, offset_vec);			
%		}
%	} 
%\end{lstlisting}
Posledn� volan� ve�ejn� funkce agenta je \texttt{step()}, kter� jen posouv� intern� ukazatel �asu v~agentovi o~d�lku kroku simulace.
%\begin{lstlisting}[caption=Funkce step(), label=lst:step, firstnumber=635]
%	void step() {
%		actual_time+=step_length;
%	}
%\end{lstlisting}

\subsection{Chr�n�n� funkce}

Chr�n�n� (\texttt{protected}) funkce zaji��uj� v�t�inu v�po�t� v~agentovi, staraj� se o~sestaven� o�ek�van�ch �as� p��jezd� vozidel k~soused�m, hled�n� optim�ln�ho offsetu, po��t�n� hodnocen� a~tak podobn�.

Funkce \texttt{expected_cars()} sestavuje �daje o~p��jezdech vozidel 
�echny sousedy. Odhady jsou zalo�eny na aktu�ln� hodnot� offsetu ulo�en� v~prom�nn� \texttt{planned_offset} a~jsou na z�v�r ulo�eny do vektoru \texttt{outputs} ur�en�mu k~odesl�n�. 

V�po�et prob�h� podle rovnic (\ref{eq:tz}) a~(\ref{eq:tk}). Po�et vozidel je z�sk�n jako sou�in odhadu po�tu vozidel, kter� projedou j�zdn�m pruhem za dobu rozsv�cen� zelen� a~p��slu�n�ho pom�ru odbo�en� $\alpha_i$, kde $i$ je ��slo v�stupn�ho sm�ru. V�po�et po�tu vozidel, kter� j�zdn�m pruhem projedou je z�le�itost� funkce \texttt{expected_output()} ze t��dy \texttt{LaneHandler}. V~sou�asnosti tato funkce vrac� po�et vozidel, kter� projela v~minul�m cyklu. 

Pro nalezen� nejlep��ho nastaven� vlastn�ho offsetu slou�� rekurentn� funkce \texttt{int find_best_offset(cont int center, int interval)}. Ta hled� ze t�� hodnot offset�: $\mathtt{center}+\mathtt{interval}$, $\mathtt{center}$ a~$\mathtt{center}-\mathtt{interval}$ hled� tu s nejlep��m hodnocen�. Nalezen� hodnota se pak pou�ije jako prvn� parametr pro dal�� vol�n� sebe sama, jako nov� interval se vezme polovina p�edchoz�ho. Toto vol�n� prob�h�, dokud \texttt{interval} nedos�hne hranice \texttt{find_best_limit}. Pak je funkce ukon�ena a~je vr�cen nalezen� offset.

Funkce zkoumaj�c� efekty zm�n offsetu u~souseda m� prototyp \texttt{int find_best_exps (const int offset_change, const string neighbour, double \&rating_change)}. V�stupem je nalezen� zm�na offsetu. Parametr \texttt{offset_change} zna�� o~kollik sekund bude agent zkou�et posunout soused�v offset, \texttt{neighbour} je jm�no zkouman�ho souseda a~do prom�nn� \texttt{rating_change} bude ulo�ena zm�n hodnocen�, kterou nalezen� nov� offset pravd�podobn� p�inese oproti sou�asn�mu stavu. Funkce si nejprve p�iprav� hodnoty o�ek�van�ch p��jezd� tak, jak by pravd�podobn� vypadaly p�i zm�n� sousedova offsetu v~kladn�m a~v~z�porn�m smyslu o~hodnotu \texttt{offset_change}. N�sledn� pak vypo��t� hodnocen� s~t�mito a~bez t�chto zm�n. Zm�na s~nejlep��m hodnocen�m je n�vratovou hodnotou funkce. 

Po��t�n� hodnocen� prob�h� ve funkci \texttt{double count_rating(const int offset, const vec recieved_exps, const RV rv_recieved_exps)} n�kolika vno�en�ch cyklech. Vn�j�� prob�h� p�es v�echny (vjezdov�) j�zdn� pruhy k�i�ovatky. Pro ka�d� pruh n�sleduje ve vno�en� smy�ce hled�n� o�ek�van�ch p��jezd� ve vektoru p�ijat�ch dat \texttt{recieved_exps}. Pokud o nich nejsou pro zkouman� pruh informace, nebude se zapo��t�vat do hodnocen�. 

V p��pad� nalezen� n�jak�ch p�edpoklad� jsou tyto ulo�eny do vektor� \texttt{t_cars_begin} (za��tky p��jezd�), \texttt{t_cars_end} (konce p��jezd�) a \texttt{cars_density} (hustoty vozidel) pro dal�� v�po�et. Ten za��n� zji�t�n�m rozsv�cen� zelen� v sign�ln� skupin� p��slu�n� dan�mu j�zdn�mu pruhu, se zapo��t�n�m offsetu p�edan�mu funkci v parametru \texttt{offset}. Intervalem sv�cen� zelen� je pak funkc� \texttt{expand_greens()} s periodou $T_{\mathrm{c}}$ zopakov�n tak, aby pokryl cel� �asov� �sek, pro kter� jsou k dispozici informace o p��jezdech vozidel. 

Ze znalosti o�ek�van�ch p��jezd� a stavu semafor� b�hem nich pak vych�z� vypo��t�v�n� p��sp�vku k hodnocen�. Ten prob�h� v \texttt{do} -- \texttt{while} cyklu. Pro jeho ��zen� je definov�na prom�nn� \texttt{t_act}, p�edstavuj�c� ukazatel na pr�v� zpracov�van� okam�ik ve zkouman�m intervalu. Jej� hodnota za��n� na 0 a pokud dos�hne hodnoty prom�nn� \texttt{t_limit}, zp�sob� ukon�en� smy�ky. Do prom�nn� \texttt{t_limit} je ulo�en �as posledn�ho zhasnut� zelen�, z�skan� z v��e zm�n�n� funkce \texttt{expand_greens()}. \texttt{t_act} se tedy b�hem v�po�tu posouv� po v�znamn�ch bodech intervalu a v ka�d�m takov�m bod� se ov��uje, jak�ho typu (dle definice z kapitoly \ref{sec:navrh}) je n�sleduj�c� interval. Podle toho se zjist� p��slu�n� d�lka virtu�ln� fronty $Q_V^{(i)}$ a pokud je tato z�porn�, ode�te se od hodnocen� \texttt{rating}. 

Po t�, co funkce projde v�echny j�zdn� pruhy, vr�t� v�slednou hodnotu ulo�enou v prom�nn� \texttt{rating} jako�to hodnocen� nastaven� s dan�m offsetem a dan�mi p�edpoklady o p��jezdech vozidel.

\texttt{GreenWaveTrafficAgent} pak je�t� obsahuje n�kolik pomocn�ch funkc� usnad�uj�c� a~zp�ehled�uj�c�ch v�po�ty. Jde nap��klad o~p�evod libovoln� prom�nn� na typ \texttt{string}, nalezen� indexu minim�ln�ho prvku ve vektoru �i hled�n� indexu (po�ad� v~konfigura�n�m souboru) zadan� sign�ln� skupiny.

Za zm�nku stoj� funkce \texttt{int normalize_offset(int offset, bool zero=true)}. Ta prov�d� posun zadan�ho \texttt{offsetu} tak, aby zapadl do ��dan�ho intervalu. P�i vynech�n� druh�ho parametru jde o~interval $\left<-\frac{T_{\mathrm{c}}}{2};\frac{T_{\mathrm{c}}}{2}\right>$, pokud m� druh� parametr hodnotu \texttt{false}, pak $\left<0;T_{\mathrm{c}}\right>$. Druh� forma normalizace se prov�d� p�ed zasl�n� offsetu �adi�i k�i�ovatky, ten toti� hodnotu v~dan�m intervalu o�ek�v�. Prvn� forma je d�le�it� pro pr�m�rov�n� offset�. Pokud by nebyla pou�ita (nebo pokud by se pou��vala druh�), nebyl by ve v�sledn�m pr�m�ru zahrnut fakt, �e hodnota $x$ a~$x+T_{\mathrm{c}}$ je v~p��pad� nastaven� offsetu toto�n�. 